Shivering on the 49th Parallel
Thursday, 28 January 2010
About a week later the server died. I diagnosed over the phone that it was the power supply and rather than travel over for 5 hours & a ferry ride and then have to stay over just to replace a $100 power supply, I had them take it to a local computer store and have them replace it.
Thursday, 28 January 2010 11:23:10 (Pacific Standard Time, UTC-08:00) | Comments [0] | Tech | Active Directory | Hardware | Microsoft | Servers#
Saturday, 23 January 2010
>(I wrote this almost a year ago and it’s been sitting in my drafts folder since then. It’s still an outstanding issue and I haven’t figured it out yet)
Saturday, 23 January 2010 18:36:00 (Pacific Standard Time, UTC-08:00) | Comments [3] | Mail Server | Networking#
Friday, 22 January 2010

WSUS is a pretty cool piece of software. Basically it acts as a “Windows Update” server for your network. Rather than have all your computers download the same updates each from Windows Update, your WSUS server dowloads it once and then distributes it to all the computers that need it over your LAN connection which is much speedier than 99.9% of the internet connections out there. It also gives you a single place to go to and approve updates. Heard bad things about an update? Don’t approve it for installation and it won’t make it’s way onto any of your machines until you do (or they release an update to supersede it). A nice solution for small and medium sized networks.

You can extend it out to different geographical sites, too. Using a downstream replica server, you can have your server in another office “take it’s lead” from your server and either download the updates from you, or (and this is cool) only download updates that you’ve approved on your server from Microsoft’s servers. If you have a metered or slow connection between the offices, this is a great solution. You still only have one place to approve/deny updates, but you don’t chew up bandwidth pushing the updates from Office A to Office B.

This is the setup that I have. I have six offices (and two satellite offices but they’re not part of the corporate network) and aside from head office, there’s only one server in each location. These servers are Domain Controllers (for logins & resource management), WSUS downstream replicas for Windows Updates, and File & Print servers for that office.

WSUS uses Group Policy Objects (GPOs) to configure your clients (XP, Vista, Windows 7, Server 2003, 2003 R2, 2008, 2008 R2) to look at your own server for Windows Updates, as well as how often to check, and whether or not to allow the users to defer a restart so as not to interrupt them in the middle of something. Here’s where my setup gets trickxy.

I have a GPO called WSUS-Office A that I apply to the Active Directory Site called “Office A” so anyone who logs in at Office A will have their Windows Update Automatic Updates (WUAU) client pointed at the local server. Other offices have their own GPO assigned to their sites to keep everyone looking at the closest/fastest server/connection.

The hitch I ran into today was with my servers because of the Out Of Bound security bulletin released by Microsoft today for MS010-002. Because of the Big Scary Crisis surrounding it, and the fact that it was listed as Critical and affecting IE 6, IE7 and IE8 on Windows 2000 SP4 all the way up to Windows Server 2008 R2, I manually synchronized my WSUS with Microsoft this morning, downloaded the updates and approved them.

I also did a dirty thing to my users: I set a deadline in WSUS of noon today for the installation. That means that they’ll be notified of the download, and if they click the little yellow shield it will install it and then say “Time to restart!” but they can click Restart Later. Once the deadline passes, however, they don’t have a choice. the window comes up and says “restart your computer or I’ll do it for you” and starts a 15 minute countdown timer. I don’t do it often, so they know that I only do it for “critical” updates. Plus I emailed everyone last night and told them it was happening and posted it on the Intranet as an announcement. This morning they all got a second email that it would happen shortly.

Where the patch wasn’t installed was on some of my servers. Some of them got the update, and some of them installed it and rebooted without warning (oops, but they were warned). I started looking into why some of the servers installed it and some didn’t. My first thought was that the Server 2003 servers did but the Server 2008 & R2 servers did not. I thought perhaps that the GPO didn’t apply to/configure the Windows 2008 clients, but that was wrong, too.

Finally I compared a 2008 virtual machine’s Windows Update screen (which wasn’t working) to a 2008 physical machine’s Windows Update screen (which was). The 2008 VM said “You receive updates: For Windows and other products from Microsoft Update” and the 2008 host said “You receive updates: Managed by your System Administrator” Further investigation into the registry (HKLM\Software\Policies\Microsoft\Windows\Windows Update\AU\) showed that the settings that were specified in the GPO were applied to the 2008 Host, but not the 2008 VM.

It then dawned on me that the difference between the two was the host was a member server and the VM was a domain controller. That led me to GPresult and Group Policy Modelling. Using the DC and Administrator accounts, the GPO (identified by a GUID rather than it’s name) that was applied to the site was denied application due to SOM (Scope of Management).

I expanded the forest folders and drilled down to the Domain Controllers OU and saw a blue exclamation mark on it. Blocked Inheritance. That meant that the Domain Controllers OU was going to not inherit any settings from GPOs ‘above’ it, including sites.

So my choices at this point are to remove the block and let everything apply to the DCs. Not a very good idea. There were three policies which would have applied to the DCs: the Default Domain Policy, Remote Desktop Policy and Office 2007 File Format Policy.

The Office 2007 File Format Policy is tame, all it does is make the default filetype for saving the Office 97-2003 compatible instead of the new .docx, .xlsx and .pptx formats. Remote Desktop Policy is equally benign. It’s denied to Domain Admins and auto-disconnects clients from Remote Desktop after 10 minutes of inactivity so it wouldn’t really apply anyway.

The Default Domain Policy had a fair amount of settings in it though: Firewall settings, password policies, that sort of thing which I don’t necessarily want to apply to my Domain Controllers.

SO, removing the Block Inheritance setting probably wouldn’t be a good idea.

The other thing I could do is apply the WSUS-Office A policy to the Domain Controllers OU. It would get around the Block Inheritance issue without applying the default domain policy to them, but it would also “point” each of my offices’ Domain Controllers back here over the slow, metered internet connection. Not ideal either.

The other thing I could do is copy each of the WSUS-OfficeX policies and then apply ALL of them to the Domain Controllers OU and use filtering to make sure that each office’s policy only applies to that office’s WSUS server. That doubles the amount of work I’d have to do if I changed one of the servers though, and if I forgot, it would mean that one of the Domain Controllers was pointing at a non-existing Update Server which could leave it unprotected/unpatched. Guh. Meh. Not ideal.

SO that’s where it stands now. I haven’t done anything yet. I’m remembering in the short term to manually check the DCs for Windows Updates until I can come up with a little more elegant solution to the GPO filtering situation.

Friday, 22 January 2010 17:00:00 (Pacific Standard Time, UTC-08:00) | Comments [0] | Tech | Microsoft | Servers | Windows#
Thursday, 21 January 2010

(This is a crosspost from the Autodesk Discussion/forum website that I was participating in)

Since I started here 15 months ago, I've been wary of messing with NLM because I didn't understand it. I still don't know all of it, but I know a lot more thanks to Travis and the rest of the contributors NLM isn't as big of a scary monster as it was before! There were Group Policy entries in my domain that were specifying an environment variable for the local license server (distributed model) by IP address, and then the next biggest office as a secondary, and third biggest as tertiary--by IP address. So for example if you logged in to a computer in site A your environment variable would be ADSK_FLEX_LICENSE=@;@;@ It worked, it was working, so I had no motivation to change it.

While checking some things out on Travis' suggestions, I changed it to a server name, so on my test computer in site C, the environment variable was ADSK_FLEX_LICENSE=@SiteC_server;@SiteA_Server;@SiteB_Server and it worked. I then changed all my environment variables to computer (NetBIOS) names.

That sorted out 4 of my 5 offices, just the 3rd one, Site C users were still grabbing licenses from sites other than their own. Further investigation showed that two of the users who were using the wrong license server hadn't logged out and back in for some time. (this prompted a quick meeting with the CAD Manager and the Sustainability Committee to make changes to inactivity timers and lock computers after one hour, log users off after 2 and go to system standby after 3 hours outside of regular business hours). When one of the problem users logged back in and started up AutoCAD, they did not get a no license error, but rather Autocad seemed to hang for a good 60-90 seconds with an hourglass... after that AutoCAD started up normally and she was on the correct license server. I did the same thing to the the other user and got similar results.

So in the end, there was some sort of networking issue (which is still undiagnosed) that was causing clients to skip over their own license server, but changing environment variables from IP address to NetBIOS names fixed the problem.

Later in 2010 we may implement other changes recommended here and move to a single/redundant license server instead of the distributed model.

Thursday, 21 January 2010 10:25:31 (Pacific Standard Time, UTC-08:00) | Comments [0] | Autocad | Networking#
Friday, 01 January 2010

First post of the new decade... maybe I won't let this place grow cobwebs in 2010 like I did in 2009 ;)

Friday, 01 January 2010 00:02:19 (Pacific Standard Time, UTC-08:00) | Comments [0] | Misc#
Admin Login
Sign In
Pick a theme: