Tag Archives: Active Directory

Time to Upgrade your Domain Controllers?

When do you upgrade your domain controllers?  As soon as the latest version of Windows comes out?  The first service pack for the latest OS?

Being a consultant, I really have no domain controllers of my own to worry about, but by and large, what I see is that clients upgrade their domain controllers when they “have to”.  The biggest “have to” issue I see typically revolves around the application of Group Policies.  It seems as you move up Microsoft’s OS scale, from Windows Server 2000 to Windows Server 2012R2, you can do more with Group Policy because each OS introduced new and improved GPOs and as VDI interest transitioned into more actual projects, the latest GPOs are becoming less luxury and increasingly necessary in order to properly manage the EUC environment.  Windows 2003 GPOs were sufficient for managing Windows XP, but were not so for Windows 7, thus when implementing Windows 7, many clients also upgraded their domain controllers to Windows Server 2008R2 to better manage the desktop environment.

Well, Windows 2012R2 and 8.x are upon us….do I upgrade my domain controllers?  Speaking for myself, though customers are talking more about Windows 8.x for their VDI environments, nobody has “pulled the trigger” so to speak and so I’m still doing Windows 7 based VDI projects and so one might think they have no need to upgrade the DCs yet….honestly, I thought that way until this weekend and now have a second reason one may feel “forced” into a domain controller upgrade.

I was looking at some XenApp servers, whose computer objects are in a separate OU with a separate GPO to ensure that some specific XenApp settings are applied only to the XenApp servers and users accessing them.  The required change was easy enough; the proxy server IP had changed and so I needed to edit the XenApp Server Policy and set the proxy server IP from 172.16.1.1 to 10.1.255.4 using the Internet Explorer Maintenance settings under the User Configuration. I made the change, went to each XenApp server, did a gpupdate /force to help speed up the application, and just waited a few moments for the sure application of the setting.

Only I waited and waited, and the setting never changed so I did what I’m sure at least some of you have done….I typed gpupdate /force with a little more force as if the computer will understand, “Oh, he’s serious, I better apply the settings this time.”  But still the settings did not apply!  Do I start looking at other things or should I type gpupdate /force even harder?

I started looking at other things.

I used the gpresult /H gpresults.html (with less intensity than I used on the second gpupdate /force command) to pipe my GPO applications to an HTML file I could then review using Internet Explorer.  I saw that even though I had changed my policy to set the new IP of the proxy server, it was still applying the original value using the updated policy.  What?!

Over the course of the next several hours, I checked the following:

  • every single GPO in the organization to ensure that the 172.16.1.1 proxy server option was not set anywhere….it was not
  • local policies with gpedit.msc
  • local registry settings
  • asked if anyone used netsh or proxycfg.exe to hard-code the proxy settings – nobody claimed to
  • I think I executed gpupdate /force 673 times – its gotta work at some point right?
  • I paced around the room, walked around the block and then decided to apply the Citrix XenApp Policy to a test server in it’s own OU – and it WORKED!!  Ran gpupdate /force the 674th time on the XenApp servers but still nothing

At this point, I gave gpupdate /force a break and asked myself, “What’s different between the 2 systems?”  These machines were VMs, same OS, built using the same VM template, etc…but certainly the Windows Updates were different as well as the versions of Internet Explorer.  The test server had IE 9, while my XenApp servers have IE 10 installed….but surely, that can’t be it can it?

I suppose some of you can see already where this is going, but it turns out that was the problem.  In Thommck’s blog post found here, he provides a rather insightful snippet from the IE 10 Deployment Guide:

Important – Any settings that you previously configured with IEM will no longer work on computers where Internet Explorer 10 or newer is installed, regardless of the Windows version it’s been installed on.

Oh yes, thank you Microsoft!  With IE 10 and above, you have to configure IE settings using Group Policy Preferences!! But upon review of the Preference settings on our existing Windows 2008R2 domain controllers, we could only set IE preferences up to version 8.  So what did we have to do?  Upgrade our domain controllers to Server 2012!  Nah, we weren’t forced to upgrade our domain controllers, but we did install the Group Policy Management feature on an existing 2012 server….after doing do, we saw the option to configure Internet Explorer 10 preferences as shown below:

1_IE10

Within the preferences policy, we set the proxy server URL and yes, performed yet another gpupdate /force on the XenApp servers but ‘Praise be’, the new proxy URL/IP applied and our Citrix users could once again surf the net!

One thing to remember about applying settings through Preferences however….some settings are “disabled” by default as shown by a dotted red line, like the proxy server setting as shown below.  Once you put the appropriate value in the setting, be sure to press F5 to enable it to save yourself some aggravation.

Long story to say that you may want to consider DC upgrades to 2012+ if you are deploying IE 10+ in your environment, you may not be able to wait until Windows 8.x is deployed via VDI or otherwise.  Personally, I prefer to perform my GPO management tasks on my DCs so instead of loading member servers to run GP Management, I suggest upgrading your DCs to make it easier on yourself in the long run.

Leave a comment

Filed under Active Directory, Citrix, Microsoft, VDI

Windows 7 VDI – Sits at Welcome screen “forever”

When deploying View/Unidesk based virtual machines for VDI, I like to use Group Policies to deploy printers….more specifically, I create printers using policies located under User Configuration | Preferences | Control Panel Settings | Printers.  Again, I have found this method of deploy printers pretty easy and reliable.

Recently, I’ve had issues with non-persistent desktops sitting at the Welcome screen for what feels like an eternity when you’re in front of a computer and staring at it.  I’ve seen persistent desktops take up to several minutes to finally complete whatever it is they’re doing and present the desktop to the end user.

Looking at the event log to investigate, I saw several events which stated the following:

The Winlogon notification subscriber <GPClient> took ### seconds to handle the notification event (Logon)

As you might expect, the number of seconds displayed in Event Viewer was the same time I was waiting for the computer to bypass the Welcome screen.  Googling the problem, I eventually saw that several people had the issue and that it was solved by disabling the “Point and Print Restrictions” GPO found at Computer Configuration | Policies | Administrative Templates | Printers

PP-GPO

A more detailed explanation of the Point and Print Restrictions policy can be found here.

Again, the problem seems to arise when using Control Panel Printer Preferences to map printers to non-persistent desktops…I’ve not experienced this issue in another scenario to  this point but after making this policy change (disabling Point and Print Restrictions), the time spent on the Welcome screen decreased dramatically.

Leave a comment

Filed under Active Directory, Microsoft, VDI, VMware, Windows Desktops