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 <[email protected]> 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 [email protected]
with the body: unsubscribe ntsysadmin
