Category 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

GPOs, SYSVOL and permissions mismatch

Have you ever seen the following error when in the Group Policy Management Console?  Clicking OK is supposed to fix the issue but in my experience, it never does.

From what I can tell from a quick search, it looks like this will occur if you do not have the permission to change the security settings of a given GPO and the solutions, or potential solutions, to resolve the error range far and wide.

Personally, I’ve been able to resolve the problem in this way:

  • Open the GPMC
  • Highlight the problem GPO
  • Click the Delegation tab
  • Click Add
  • Give a user or a group Read permissions and click OK
  • Then remove the permissions you just assigned.

I’m not sure if this works everywhere, honestly I doubt it does, but its easy and worth a shot.

Leave a comment

Filed under Active Directory, Microsoft

Restoring a Domain Controller using Backup Exec 2012 SDR – Part 2

I ended part 1 with the creation of the SDR ISO.  This ISO can be used with VMs (though you probably wouldn’t restore VMs with this) or burned to a CD for physical systems.  Once the SDR disc is created, boot a machine with it in order to perform a system recovery.

Here’s more from the Backup Exec help topics concerning the SDR process:

You start a computer with the Simplified Disaster Recovery Disk, and then use the Recover This Computer link on the Recovery tab to recover the computer. The recovery disk uses a minimal version of the Windows 7 operating system and contains many of the drivers that are required to recover your computer. In many cases, the generic Simplified Disaster Recovery Disk can be used to completely recover the computer. However, if you change the computer’s hardware after the last SDR backup, the generic Simplified Disaster Recovery Disk might not be sufficient to recover the computer. You should run the Create Simplified Disaster Recovery Disk Wizard to determine if the generic Simplified Disaster Recovery Disk recognizes any new hardware drivers that are not present in its driver database. If the drivers are present, you can use the generic Simplified Disaster Recovery Disk to recover the computer. Otherwise, use the Create Simplified Disaster Recovery Disk Wizard to create a custom Simplified Disaster Recovery Disk for the computer, and then store the custom recovery disk in a safe location.

Again, I was using a VM to test the process of restoring a dead domain controller assuming an entire domain failure.  In my case, my test VM:

  • Had the same OS as the original machine
  • Had the same service pack/patches
  • Had the same disk configuration
  • Had the same backup agent installed
  • Had a different name (DC02, but it could have been anything)
  • Was not a member of the domain

With that, I booted my new machine with my SDR Disc (after ensuring the CD-ROM was listed first in the boot order in the BIOS).

1. When prompted, accept the Symantec license agreement.

2. On the Welcome to the Simplified Disaster Recovery Disk window, click Recover This Computer

3. On the Where is this computer’s backup data located screen, select The data is located on devices attached to a remote Backup Exec server.

4. On the To which Backup Exec server do you want to connect screen, enter the Backup Exec server information and AD credentials then click Next.  In my test scenario, I’m assuming the AD credentials worked because I had already logged into the Backup Exec server with this account.  I’m guessing a different account would have failed…

5. On the Which backup sets to recover screen, select the Computer and Point in time of the backup to restore and click Next.

6. On the Do you want to use this volume layout for the specified backup sets screen, assuming your disk configuration is the same, you should be able to select your disk and click Next.  However, I had a problem in that the wizard believe my new disk configuration was different, though it wasn’t (second screenshot).  I ended up enabling the option to “Erase hard disks and recreate the volume layout shown above” to get past the disk layout problem.

Once the problem with the disk layout was “resolved”, I clicked Next…..

7. On the Recovery Summary screen, click Recover to begin the restoration.

8. The server is restored as shown below.  When the recovery process completes, click Finish.

9. On the main recovery screen, click Exit and reboot the server.

10. When the server boot, test Active Directory.

This was just an easy test with a single domain controller.  If multiple domain controllers existed in the environment, you could use the same process to restore them or you may decide to build new domain controllers in a virtual environment.  If you will not restore other domain controllers, use NTDSUTIL to seize any FSMO roles and remove those domain controllers before you introduce new DCs into the domain.

Certainly there are many ways to restore servers….I’m not saying this is the only, or even the best way to do so, but I was impressed with how easy Backup Exec has made the recovery process.  Typically I work with virtual servers so I may never run this process again but I believe its beneficial to know. 

1 Comment

Filed under Active Directory, BRS/DR, Microsoft

Restoring a Domain Controller using Backup Exec 2012 SDR – Part 1

I think I’ve said this before but I’ll say it again….as a consultant I see a lot of technologies and being a consultant also means that I am typically onsite for 1-3 weeks on a given project and then I’m gone to the next one.  One thing I don’t spend a great deal of time doing is basic Microsoft maintenance/backup/recovery tasks.  I had some time this week and was thinking, “How hard is it to recover from a complete domain failure using Backup Exec 2012?”  Why, who the heck knows but it was there.  So I used VMware Workstation to build the following: (“pretending” like these VMs are physical servers thought I don’t see many physical-only environments anymore)

  • DC01 – Windows Server 2008R2 Standard – Active Directory domain controller
  • BACKUP01 – Windows Server 2008R2 Standard – Backup Exec 2012 server
I then:
  • Created some OUs, user accounts, and security groups in my domain
  • From Symantec, downloaded the Backup Exec 2012 Installation and SDR (Simplified Disaster Recovery) ISOs
  • Installed Backup Exec 2012 on BACKUP01
  • Extracted the SDR ISO
  • Installed the Backup Exec Agent on DC01
  • Performed a backup of DC01 (to disk) using the One-Time Backup wizard
  • Used the Create Disaster Recovery Disk wizard to create a custom ISO based on the SDR ISO and the successful backup job 
  • Once the backup was successful, I shutdown DC01 and deleted the VM to simulate my complete domain failure

About Backup Exec SDR

Concerning SDR, the following text was taken from the Help Topics from within Backup Exec and provides a pretty good overview of SDR and its intended functionality.  In a nutshell, SDR makes it easier to restore machines that have experienced a hard-drive or system component failure.

Symantec Backup Exec Simplified Disaster Recovery (SDR) enables you to quickly and efficiently recover Windows computers after a hard drive failure.  The SDR wizards guide you in preparing for disaster recovery and in recovering a local or remote computer to its pre-disaster state.

Simplified Disaster Recovery (SDR) works with Backup Exec when you run backup jobs that include all critical system component selections.  For each computer that you protect with this type of backup job, Backup Exec creates a disaster recovery information file for that computer.  A disaster recovery information file contains computer-specific information for the computer being backed up.  Computer-specific information includes details such as hard disk layout, storage drivers, network drivers, and system version details.  It also includes Backup Exec catalog details such as backup set information and recovery point details.  Each disaster information recovery file uses the file name .DR.

Backup Exec automatically stores each disaster recovery information file it creates in a default location on the Backup Exec server.  Because the files are critical, Backup Exec also lets you specify an alternate storage location where an additional copy of each file can be stored.  Symantec recommends that you set a path to an alternate storage location.  If the Backup Exec server crashes, you won’t be able to retrieve the disaster recovery information file from the default location but you can retrieve it from the alternate location.

Each time Backup Exec runs a backup that includes all critical system components, the disaster recovery information files are automatically updated in each storage location.

SDR uses the computer-specific information that is contained in the file when you run the Recover This Computer Wizard.  Without a disaster recovery information file, a local recovery of the computer is not possible with SDR.


Simplified Disaster Recovery (SDR) is automatically installed on the Backup Exec server during the initial installation of Backup Exec. However, the Agent for Windows is required to protect remote computers with SDR. You must purchase the Agent for Windows separately, and then install it on the remote computers that you want to protect. The Agent for Windows is a system service that runs on remote servers and enhances backup and restore performance.

Creating the Disaster Recovery Disk

Once my backup of DC01 completed successfully, I used the Create Disaster Recovery Disk wizard to create a custom boot-able ISO used for SDRs.

1. Within BE, click the BE icon button on the upper right-hand side of the screen and then select Configuration and Settings | Create Disaster Recovery Disk

2. On the Welcome to the SDR Disk Creation Wizard screen, click Next.

3. On the Source Location screen, select From an image (.iso) file and then click Browse to specify the location of the SDR ISO downloaded from Symantec.  Click Next to continue.

4. On the Select computers to use the drivers from screen, select the computer to serve as the template for network and storage drivers and click Next.  In a production environment, I’m assuming you may consider created a SDR disk for each physical hardware type you support, or you may be able to use the “Drivers to Include” option shown on step #5 to consolidate various drivers onto a single SDR ISO.

5. On the Drivers to Include screen, select Add Driver to browse for additional driver .INF files to load into this SDR ISO and click Next.

6. On the Select Location for CD Image screen, enter a Volume Label and Image file name (.iso) and click Next.  Though I didn’t do it below, it may be more beneficial to include the physical device type in the ISO name…

7. On the Startup Options screen, specify the Time zone, Language, and Keyboard layout settings and click Next.

8. On the Summary screen, review the settings and click Create Image.

9. The disk will be created as shown below, when it is Finished, click Next.

10. When the new SDR CD Image has been successfully created, click Finish.

I’ll continue with part 2 detailing the steps I took to restore my domain controller in the next post.

Leave a comment

Filed under Active Directory, BRS/DR, Microsoft