You got to love management that does not look before they leap!....NOT! Jon > Date: Fri, 15 Mar 2013 18:05:01 -0700 > Subject: Re: Lync issue - something I don't quite understand... > From: [email protected] > To: [email protected] > > Unfortunately starting over wasn't an option - too many people already > using it and have contact lists built, so that got nixed. > > What's even better is that the manager of the department found a > script to enable accounts for Lync, and ran it at the root of the > domain - so now all of our service accounts, disabled accounts, and > everything have Lync access. > > Some day I'm going to have to clean all of that up. > > Kurt > > On Fri, Mar 15, 2013 at 5:05 PM, Jon Harris <[email protected]> wrote: > > Ah wouldn't have been easier to just trash and start over, but congrats on > > finding and fixing most of the issues. When you get the backups working > > correctly you will at least know the correct way to set up Lync. > > > > Jon > > > >> Date: Fri, 15 Mar 2013 11:33:42 -0700 > > > >> Subject: Re: Lync issue - something I don't quite understand... > >> From: [email protected] > >> To: [email protected] > > > >> > >> 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 <[email protected]> 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 <[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 > > > > ~ 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 > > ~ 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 ~ 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
