Oh, yeah - I also deselected Register with DNS on the NIC in the DMZ. Kurt
On Fri, Mar 15, 2013 at 11:31 AM, Kurt Buff <kurt.b...@gmail.com> wrote: > Followup on my problem - it's solved, and here's what the problems(s) > were and the solution(s) > > Turns out that not only did both NICs have a DG, but the one that was > supposed to be present in the server subnet was in a switch port that > was tagged in a completely unrelated VLAN. No connectivity on that > port *at all*. > > Also, the NIC that was working had an address that wasn't correct - it > didn't match my list of addresses. > > So, I did several things: > > o- Renamed the NICs to Internal and External, so that they're easy to track > > o- Readdressed the NICs to correct addresses > > o- Bound the Internal and External web sites to the proper IP addresses > > o- Moved the External NIC to the DMZ (Yes, I recognize the irony of > that, given (especially my statements in) the recent conversation on > DMZs and security, but I am constrained in my resources, and *have* to > get this going . In my defense are the following: 1) there are *no* > external users currently 2) There is no egress for this box through > the DMZ, so basically no egress at all, since the DG is blocked for > this machine and the static routes are only for internal subnets and > 3) I plan on putting up an edge server under appropriate controls > before we allow any external users. So there!) > > o- Set up static routes on the machine for all of the internal subnets > for the internal NIC, and left the new DG on the external NIC. I > found these to incantations to work just fine: > netsh interface ipv4 add route <subnet to be routed> <name of > interface> <destination address> > > netsh interface ipv4 delete route <subnet being routed> <name of > interface> <destination address> > > > I then noticed a whole bunch of errors in the application event log > (41001 for LS LDM), and web conferencing didn't work any longer. The > event read: > > Cannot initiate connection to Web Conferencing Edge Server. > > URL=tcp://poo01.example.com:8057, Error=0x80072AFC > Cause: Invalid Web Conferencing Edge Server FQDN > Resolution: > Validate Web Conferencing Edge Server configuration > > Well, there is no edge server. An hour or so of googling was not > hugely productive, so I tried to bang around in the the Lync Control > Panel - but it wouldn't launch with the standard URL. I found that to > be quite odd. However, I was able to get a couple of things up on the > server by using the IIS manager and selecting browse by IP address. > So, I changed the URL for the LCP to use the IP address, and it came > up. > > I then noticed that there was an entry for Topology. I ran through > that until I noticed where the old IP addresses were embedded. So, I > published the toppolgy, and got a number of errors. > > Turns out the person who set this up did so with a DA account, and > didn't use the server administrator account group I had set up as > members of any of the groups for managing Lync. So, I visited all of > the groups, added the appropriate server manager group to them, and > was able to publish the topology. > > Done. > > Now it's back to unscrewing the backup process that he has so > thoroughly pooched, and see if we can get an error-free backup to tape > and offsite... > > Kurt > > On Wed, Feb 27, 2013 at 4:56 PM, Kurt Buff <kurt.b...@gmail.com> wrote: >> All, >> >> We've got a Lync 2010 infrastructure set up, but it's doing one little >> thing that I'm not liking. >> >> The server has two NICs - each in a different subnet. One is in the >> same subnet as the rest of our servers. The other is in a subnet that >> sits between our L3 switch and our firewall - it's not a DMZ. >> >> I didn't set this up, but I was told that the intention was to set up >> the second connection in the DMZ at the appropriate time for external >> access - that hasn't happened yet, and I wasn't involved in the >> install, and know little to nothing about Lync. >> >> The behavior I'm seeing is that I cannot ping the interface that's on >> the server subnet at all, including from machines on that subnet (I >> can't RDP to that IP address either). The name of the Lync server >> resolves to an IP address, and which one you get depends on the state >> of DNS - you might get back the one for the server subnet, or you >> might get back the other address. I can ping the other address just >> fine. >> >> So, where I'm going with this is: Both NICs have default gateways >> assigned, and in my experience, that's a largish mistake - only one >> interface should have a DG. I suspect this is causing some other >> problems that we are seeing as well >> >> However, the fellow who set this up swears that if I remove the DG >> from either NIC, Lync will break. >> >> So, do any of you here know enough about Lync to say if having only >> one DG will break it? >> >> Thanks, >> >> Kurt ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin
