This may come as a shock to some of you but I do not use PowerShell for this task.  Instead, I use built-in Windows utilities that I have been using since probably around 2004.  What I use works, so I see no need to redo it in PowerShell. I only use three Windows utilities:

• DSAdd
• DSMod
• DSQuery

I have a batch file that does the following:

• Creates the OUs
• Creates the security groups
• Creates the user accounts
• Adds the user accounts into the security groups
• Creates the computer accounts

I pre-create all the computer accounts so when the computers are joined to the domain, they are in the right OU and get the necessary GPOs immediately after the domain join restart.

The batch file is very simple (to me).

Note: The batch file contains several “-upn something@domain.com”. These seem to confuse the syntax highlighter I use for WordPress. The highlighter treated everything after the “something@domain.com” as JavaScript and really scrambled the rest of the text. Just in the text below, I changed all the “something@domain.com” to “something at domain.com” just for this article but they are still there in the batch file you can download.

echo off
CLS

Echo Create OUs
Dsadd ou "ou=Lab,dc=LabADDomain,dc=com" -desc "top level OU for Lab"

Dsadd ou "ou=Accounts,ou=Lab,dc=LabADDomain,dc=com" -desc "Accounts top level OU"
Dsadd ou "ou=Admin,ou=Accounts,ou=Lab,dc=LabADDomain,dc=com" -desc "OU for Admin accounts"
Dsadd ou "ou=Service,ou=Accounts,ou=Lab,dc=LabADDomain,dc=com" -desc "OU for service accounts"
Dsadd ou "ou=User,ou=Accounts,ou=Lab,dc=LabADDomain,dc=com" -desc "OU for regular user account"

Dsadd ou "ou=Desktops,ou=Lab,dc=LabADDomain,dc=com" -desc "Desktops top level OU"
Dsadd ou "ou=Admin,ou=Desktops,ou=Lab,dc=LabADDomain,dc=com" -desc "OU for administrator desktops"
Dsadd ou "ou=XD76,ou=Desktops,ou=Lab,dc=LabADDomain,dc=com" -desc "OU for regular user desktops"

Dsadd ou "ou=Groups,ou=Lab,dc=LabADDomain,dc=com" -desc "Security Groups top level OU"
Dsadd ou "ou=Admin,ou=Groups,ou=Lab,dc=LabADDomain,dc=com" -desc "OU for admin security groups"
Dsadd ou "ou=Desktops,ou=Groups,ou=Lab,dc=LabADDomain,dc=com" -desc "OU for desktop computer security groups"
Dsadd ou "ou=User,ou=Groups,ou=Lab,dc=LabADDomain,dc=com" -desc "OU for regular user security groups"

Dsadd ou "ou=Servers,ou=Lab,dc=LabADDomain,dc=com" -desc "Servers top level OU"
Dsadd ou "ou=PVS,ou=Servers,ou=Lab,dc=LabADDomain,dc=com" -desc "OU for PVS servers"
Dsadd ou "ou=XD76,ou=Servers,ou=Lab,dc=LabADDomain,dc=com" -desc "OU for all other XenDesktop servers"

Echo Create security groups
Dsadd group "cn=LocalAdmins,ou=Admin,ou=Groups,ou=Lab,dc=LabADDomain,dc=com" -secgrp yes -desc "Group for users who need local admin rights"

Dsadd group "cn=XDUsers,ou=User,ou=Groups,ou=Lab,dc=LabADDomain,dc=com" -secgrp yes -desc "Group for users who need XenDesktop desktop access"

Echo Create user accounts
Dsadd user "cn=svc_ctxpvs,ou=Service,ou=Accounts,ou=Lab,dc=LabADDomain,dc=com" -samid svc_ctxpvs -upn svc_ctxpvs at LabADDomain.com -fn svc_ctxpvs -display "svc_ctxpvs" -pwd FakePwd -desc "Citrix PVS Service Account" -mustchpwd no -pwdneverexpires yes
Dsadd user "cn=svc_ctxsqldb,ou=Service,ou=Accounts,ou=Lab,dc=LabADDomain,dc=com" -samid svc_ctxsqldb -upn svc_ctxsqldb at LabADDomain.com -fn svc_ctxsqldb -display "svc_ctxsqldb" -pwd FakePwd -desc "Citrix SQL DBA Service Account" -mustchpwd no -pwdneverexpires yes

Dsadd user "cn=User1,ou=User,ou=Accounts,ou=Lab,dc=LabADDomain,dc=com" -samid User1 -upn User1 at LabADDomain.com -fn User1 -display "User1" -pwd FakePwd -desc "User1 PvD" -mustchpwd no -pwdneverexpires yes
Dsadd user "cn=User2,ou=User,ou=Accounts,ou=Lab,dc=LabADDomain,dc=com" -samid User2 -upn User2 at LabADDomain.com -fn User2 -display "User2" -pwd FakePwd -desc "User2 PvD" -mustchpwd no -pwdneverexpires yes
Dsadd user "cn=User3,ou=User,ou=Accounts,ou=Lab,dc=LabADDomain,dc=com" -samid User3 -upn User3 at LabADDomain.com -fn User3 -display "User3" -pwd FakePwd -desc "User3 PvD" -mustchpwd no -pwdneverexpires yes

Echo Add user accounts to security groups
Rem all users in the Lab/Accounts/User OU get added to the XDUsers security group
dsquery user "ou=User,ou=Accounts,ou=Lab,dc=LabADDomain,dc=com" -limit 0 | dsmod group "cn=XDUsers,ou=User,ou=Groups,ou=Lab,dc=LabADDomain,dc=com" -chmbr -c

Rem any user in the Lab/Accounts/User OU that has PvD in the description gets added to the LocalAdmins security group
dsquery user "ou=User,ou=Accounts,ou=Lab,dc=LabADDomain,dc=com" -desc "*PvD*" -limit 0 | dsmod group "cn=LocalAdmins,ou=Admin,ou=Groups,ou=Lab,dc=LabADDomain,dc=com" -chmbr -c

Echo Create computer accounts
Dsadd computer "cn=PVS76,ou=PVS,ou=Servers,ou=Lab,dc=LabADDomain,dc=com" -samid PVS76 -desc "PVS76"

Dsadd computer "cn=XD76,ou=XD76,ou=Servers,ou=Lab,dc=LabADDomain,dc=com" -samid XD76 -desc "XD76"
Dsadd computer "cn=Director,ou=XD76,ou=Servers,ou=Lab,dc=LabADDomain,dc=com" -samid Director -desc "Director"
Dsadd computer "cn=StoreFront,ou=XD76,ou=Servers,ou=Lab,dc=LabADDomain,dc=com" -samid StoreFront -desc "StoreFront"
Dsadd computer "cn=SQL,ou=XD76,ou=Servers,ou=Lab,dc=LabADDomain,dc=com" -samid SQL -desc "SQL"

echo on

The results of running the batch file.

Note: In the text below, I also had to change all the “something@domain.com” to “something at domain.com” just for this article but they are still there in the batch file you can download.

Echo Create OUs
Create OUs
Dsadd ou "ou=Lab,dc=labaddomain,dc=com" -desc "top level OU for Lab"
dsadd succeeded:ou=Lab,dc=labaddomain,dc=com
Dsadd ou "ou=Accounts,ou=Lab,dc=labaddomain,dc=com" -desc "Accounts top level OU"
dsadd succeeded:ou=Accounts,ou=Lab,dc=labaddomain,dc=com
Dsadd ou "ou=Admin,ou=Accounts,ou=Lab,dc=labaddomain,dc=com" -desc "OU for Admin accounts"
dsadd succeeded:ou=Admin,ou=Accounts,ou=Lab,dc=labaddomain,dc=com
Dsadd ou "ou=Service,ou=Accounts,ou=Lab,dc=labaddomain,dc=com" -desc "OU for service accounts"
dsadd succeeded:ou=Service,ou=Accounts,ou=Lab,dc=labaddomain,dc=com
Dsadd ou "ou=User,ou=Accounts,ou=Lab,dc=labaddomain,dc=com" -desc "OU for regular user account"
dsadd succeeded:ou=User,ou=Accounts,ou=Lab,dc=labaddomain,dc=com
Dsadd ou "ou=Desktops,ou=Lab,dc=labaddomain,dc=com" -desc "Desktops top level OU"
dsadd succeeded:ou=Desktops,ou=Lab,dc=labaddomain,dc=com
Dsadd ou "ou=Admin,ou=Desktops,ou=Lab,dc=labaddomain,dc=com" -desc "OU for administrator desktops"
dsadd succeeded:ou=Admin,ou=Desktops,ou=Lab,dc=labaddomain,dc=com
Dsadd ou "ou=XD76,ou=Desktops,ou=Lab,dc=labaddomain,dc=com" -desc "OU for regular user desktops"
dsadd succeeded:ou=XD76,ou=Desktops,ou=Lab,dc=labaddomain,dc=com
Dsadd ou "ou=Groups,ou=Lab,dc=labaddomain,dc=com" -desc "Security Groups top level OU"
dsadd succeeded:ou=Groups,ou=Lab,dc=labaddomain,dc=com
Dsadd ou "ou=Admin,ou=Groups,ou=Lab,dc=labaddomain,dc=com" -desc "OU for admin security groups"
dsadd succeeded:ou=Admin,ou=Groups,ou=Lab,dc=labaddomain,dc=com
Dsadd ou "ou=Desktops,ou=Groups,ou=Lab,dc=labaddomain,dc=com" -desc "OU for desktop computer security groups"
dsadd succeeded:ou=Desktops,ou=Groups,ou=Lab,dc=labaddomain,dc=com
Dsadd ou "ou=User,ou=Groups,ou=Lab,dc=labaddomain,dc=com" -desc "OU for regular user security groups"
dsadd succeeded:ou=User,ou=Groups,ou=Lab,dc=labaddomain,dc=com
Dsadd ou "ou=Servers,ou=Lab,dc=labaddomain,dc=com" -desc "Servers top level OU"
dsadd succeeded:ou=Servers,ou=Lab,dc=labaddomain,dc=com
Dsadd ou "ou=PVS,ou=Servers,ou=Lab,dc=labaddomain,dc=com" -desc "OU for PVS servers"
dsadd succeeded:ou=PVS,ou=Servers,ou=Lab,dc=labaddomain,dc=com
Dsadd ou "ou=XD76,ou=Servers,ou=Lab,dc=labaddomain,dc=com" -desc "OU for all other XenDesktop servers"
dsadd succeeded:ou=XD76,ou=Servers,ou=Lab,dc=labaddomain,dc=com
Echo Create security groups
Create security groups
Dsadd group "cn=LocalAdmins,ou=Admin,ou=Groups,ou=Lab,dc=labaddomain,dc=com" -secgrp yes -desc "Group for users who need local admin rights"
dsadd succeeded:cn=LocalAdmins,ou=Admin,ou=Groups,ou=Lab,dc=labaddomain,dc=com
Dsadd group "cn=XDUsers,ou=User,ou=Groups,ou=Lab,dc=labaddomain,dc=com" -secgrp yes -desc "Group for users who need XenDesktop desktop access"
dsadd succeeded:cn=XDUsers,ou=User,ou=Groups,ou=Lab,dc=labaddomain,dc=com
Echo Create user accounts
Create user accounts
Dsadd user "cn=svc_ctxpvs,ou=Service,ou=Accounts,ou=Lab,dc=labaddomain,dc=com" -samid svc_ctxpvs -upn svc_ctxpvs at labaddomain -fn svc_ctxpvs -display "svc_ctxpvs" -pwd FakePwd -desc "Citrix PVS Service Account" -mustchpwd no -pwdneverexpires yes
dsadd succeeded:cn=svc_ctxpvs,ou=Service,ou=Accounts,ou=Lab,dc=labaddomain,dc=com
Dsadd user "cn=svc_ctxsqldb,ou=Service,ou=Accounts,ou=Lab,dc=labaddomain,dc=com" -samid svc_ctxsqldb -upn svc_ctxsqldb at labaddomain -fn svc_ctxsqldb -display "svc_ctxsqldb" -pwd FakePwd -desc "Citrix SQL DBA Service Account" -mustchpwd no -pwdneverexpires yes
dsadd succeeded:cn=svc_ctxsqldb,ou=Service,ou=Accounts,ou=Lab,dc=labaddomain,dc=com
Dsadd user "cn=User1,ou=User,ou=Accounts,ou=Lab,dc=labaddomain,dc=com" -samid User1 -upn User1 at labaddomain -fn User1 -display "User1" -pwd FakePwd -desc "User1 PvD" -mustchpwd no -pwdneverexpires yes
dsadd succeeded:cn=User1,ou=User,ou=Accounts,ou=Lab,dc=labaddomain,dc=com
Dsadd user "cn=User2,ou=User,ou=Accounts,ou=Lab,dc=labaddomain,dc=com" -samid User2 -upn User2 at labaddomain -fn User2 -display "User2" -pwd FakePwd -desc "User2 PvD" -mustchpwd no -pwdneverexpires yes
dsadd succeeded:cn=User2,ou=User,ou=Accounts,ou=Lab,dc=labaddomain,dc=com
Dsadd user "cn=User3,ou=User,ou=Accounts,ou=Lab,dc=labaddomain,dc=com" -samid User3 -upn User3 at labaddomain -fn User3 -display "User3" -pwd FakePwd -desc "User3 PvD" -mustchpwd no -pwdneverexpires yes
dsadd succeeded:cn=User3,ou=User,ou=Accounts,ou=Lab,dc=labaddomain,dc=comEcho Add user accounts to security groups
Add user accounts to security groups
Rem all users in the Lab/Accounts/User OU get added to the XDUsers security group
dsquery user "ou=User,ou=Accounts,ou=Lab,dc=labaddomain,dc=com" -limit 0 | dsmod group "cn=XDUsers,ou=User,ou=Groups,ou=Lab,dc=labaddomain,dc=com" -chmbr -c
dsmod succeeded:cn=XDUsers,ou=User,ou=Groups,ou=Lab,dc=labaddomain,dc=com
Rem any user in the Lab/Accounts/User OU that has PvD in the description gets added to the LocalAdmins security group
dsquery user "ou=User,ou=Accounts,ou=Lab,dc=labaddomain,dc=com" -desc "*PvD*" -limit 0 | dsmod group "cn=LocalAdmins,ou=Admin,ou=Groups,ou=Lab,dc=labaddomain,dc=com" -chmbr -c
dsmod succeeded:cn=LocalAdmins,ou=Admin,ou=Groups,ou=Lab,dc=labaddomain,dc=com
Echo Create computer accounts
Create computer accounts
Dsadd computer "cn=PVS76,ou=PVS,ou=Servers,ou=Lab,dc=labaddomain,dc=com" -samid PVS76 -desc "PVS76"
dsadd succeeded:cn=PVS76,ou=PVS,ou=Servers,ou=Lab,dc=labaddomain,dc=com
Dsadd computer "cn=XD76,ou=XD76,ou=Servers,ou=Lab,dc=labaddomain,dc=com" -samid XD76 -desc "XD76"
dsadd succeeded:cn=XD76,ou=XD76,ou=Servers,ou=Lab,dc=labaddomain,dc=com
Dsadd computer "cn=Director,ou=XD76,ou=Servers,ou=Lab,dc=labaddomain,dc=com" -samid Director -desc "Director"
dsadd succeeded:cn=Director,ou=XD76,ou=Servers,ou=Lab,dc=labaddomain,dc=com
Dsadd computer "cn=StoreFront,ou=XD76,ou=Servers,ou=Lab,dc=labaddomain,dc=com" -samid StoreFront -desc "StoreFront"
dsadd succeeded:cn=StoreFront,ou=XD76,ou=Servers,ou=Lab,dc=labaddomain,dc=com
Dsadd computer "cn=SQL,ou=XD76,ou=Servers,ou=Lab,dc=labaddomain,dc=com" -samid SQL -desc "SQL"
dsadd succeeded:cn=SQL,ou=XD76,ou=Servers,ou=Lab,dc=labaddomain,dc=com
echo on
C:\>

And the results in AD.

And there you have the very quick and very simple way I can create and recreate my AD lab structure.  To delete the structure, I just right-click the top-level Lab OU and select delete as shown in Figure 12.

Click Yes to the popup shown in Figure 13.

Select Use Delete Subtree server control and click Yes as shown in Figure 14.

And in less than the blink of an eye, the Lab OU structure is removed from AD as shown in Figure 15.

Since DSAdd OU does not have a parameter to set the Protect this OU from accidental deletion flag, it is very simple to delete the Lab OU tree and run the batch file to recreate the Lab OU structure whenever I need to have a clean (re)starting point.

I hope this very quick and simple process helps you out.

Thanks

Webster

The following were tested:

• XenApp 5 on Windows Server 2008 Sp2, both PowerShell V2 and V3 – script versions 2 and the in development V4.
• XenApp 6 on Windows Server 2008 R2 SP1, both PowerShell V2 and V3 – script versions 3 and the in development V4.
• XenApp 6.5 on Windows Server 2008 R2 SP1, both PowerShell V2 and V3 – script versions 3.1 and the in development V4.
• The PVS version 3 script was updated to support PVS 7.0 running on Server 2012.  Server 2012 includes PowerShell V3 so the PVS script has already been tested with PowerShell V3.

All the V4 scripts are being developed exclusively with PowerShell V3.  When PowerShell V4 is released, I will retest my documentation scripts with it.

I have updated all the appropriate ReadMe files and the Where to Get Copies of the Various Documentation Scripts article.

Thanks

Webster

Excuse me why I explain the journey that took me to the article.

I am currently rebuilding my lab to learn all the Microsoft System Center 2012 SP1 stuff.  I am using only Server 2012 for all my Virtual Machines (VMs).  With all the work I am doing with Server 2012 and since I am also planning on taking the Microsoft Private Cloud certification exams, I decided I needed to take the 70-417 exam (Upgrading your Skills to MCSA Windows Server 2012).  Since I have taken well over 200 certification exams since 1998, I consider myself a professional certification exam taker.  The first thing I do when I decide to take an exam is to look at what the vendor says will be on the exam.  Citrix and Microsoft call that the Exam Preparation Guide.

The 70-417 exam is an upgrade exam for someone who already holds an earlier MCSA.  70-417 covers the same material as three other exams: 70-410, 70-411, and 70-412.  Microsoft offers a 70-417 study guide.

One of the items to be covered is recovering from a deleted GPO.  How do you recover a deleted (or from a really screwed up) Default Domain and or Default Domain Controllers GPO?  I haven’t had to recover from a deleted Default Domain GPO since 2005 or from a screwed-up one since 2008.  Well, you use the DCGpoFix command-line utility.

Since I am a reader, I read the entire article.  Lo and behold, after all these years, I actually saw in writing from Microsoft the Best Practice I had been telling people about all these years.  Right there in the first paragraph under Examples:

As a best practice, you should configure the Default Domain Policy GPO only to manage the default Account Policies settings, Password Policy, Account Lockout Policy, and Kerberos Policy.

I cannot count the number of arguments I have had with Windows Admins over this.  And wouldn’t you know, my AD mentors have been correct all these years! 🙂

I once did a troubleshooting project for a Citrix XenApp 5 on Server 2003 environment for slow logons.  It seems ever since XenApp 5 had been installed and put into production, EVERY user on the network was experiencing slow logins and many other issues.  Naturally, of course, XenApp 5 received the blame.  The actual problem?  They had put over 800 lockdown configuration settings in the Default Domain GPO!!!!  And they wondered why every user on the network was affected!!!  Instead of having a separate Organizational Unit (OU) for the XenApp servers, they put them in the Computers Container (where you cannot directly apply any GPO).  They then put all their lockdown settings in the Default Domain GPO which instantly affected everyone.

The fix?

1. Record the Account, Password, Account Lockout, and Kerberos policy settings,
2. Create an OU for the XenApp servers,
3. Create a lockdown GPO and link it to the new XenApp server’s OU,
4. Run DCGpoFix /domain to recreate the Default Domain policy,
5. Edit the new Default Domain GPO and enter the recorded settings from Step 1 above,
6. Move the XenApp servers to their new OU,
7. Reboot the XenApp servers (necessary to affect the move to the new OU), and then
8. Troubleshoot and fix remaining issues.

Projects like this are where I get the material for my “10 Things in AD…” presentations.  This is also why studying for certification exams can be beneficial.  Now I have proof I am correct in what I tell people should go in the Default Domain GPO.

Thanks

Webster

There is no way to use the in-the-box Group Policy PowerShell cmdlets to create WMI Filters.  For that, there is a Group Policy WMI filter cmdlet module available.  I downloaded the module and placed it in my scripts folder, c:\webster.  There was an issue for me and I had to change one line in the module.

I had to change line 70 from:

$msWMIAuthor = (Get-ADUser $env:USERNAME).UserPrincipalName

To:

$msWMIAuthor = (Get-ADUser $env:USERNAME).Name

Without that change, I received an error on line 97 with a Null value in the $Attr array defined in line 80.  I traced the Null value to the msWMI-Author value in the array.

The script to create the Group Policy:

Set-StrictMode -Version 2

#Carl Webster, CTP and independent consultant
#webster@carlwebster.com
#@carlwebster on Twitter
#https://www.carlwebster.com
#With help from Michael B. Smith - <a href="https://www.essential.exchange/blog/" target="_blank" rel="noopener">https://www.essential.exchange/blog/</a>

# load required modules
Import-Module ActiveDirectory
Import-Module GroupPolicy
#the following module is available for download from
#http://gallery.technet.microsoft.com/scriptcenter/Group-Policy-WMI-filter-38a188f3
#assuming the module is in the same folder as the script
Import-Module ( Join-Path ( Split-Path $MyInvocation.MyCommand.Path -Parent) GPWmiFilter.psm1 )

#define variables specific to an AD environment
$GPOName       = 'Set PDCe as Authoritative Time Server'
$defaultNC     = ( [ADSI]"LDAP://RootDSE" ).defaultNamingContext.Value
$TargetOU      = 'OU=Domain Controllers,' + $defaultNC
$TimeServer    = 'north-america.pool.ntp.org,0x1'
$WMIFilterName = 'PDCe Role Filter'

#the GPWmiFilter module said to put this in the main code
new-itemproperty "HKLM:\System\CurrentControlSet\Services\NTDS\Parameters" `
-name "Allow System Only Change" -value 1 -propertyType dword -EA 0

#create WMI Filter
$filter = New-GPWmiFilter -Name $WMIFilterName `
-Expression 'Select * from Win32_ComputerSystem where DomainRole = 5' `
-Description 'Queries for the Domain Controller that holds the PDCe FSMO Role' `
-PassThru

#create new GPO shell
$GPO = New-GPO -Name $GPOName

#add WMI filter
$GPO.WmiFilter = $Filter

#set the three registry keys in the Preferences section of the new GPO
Set-GPPrefRegistryValue -Name $GPOName -Action Update -Context Computer `
-Key 'HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config' `
-Type DWord  -ValueName 'AnnounceFlags' -Value 5 | out-null

Set-GPPrefRegistryValue -Name $GPOName -Action Update -Context Computer `
-Key 'HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters' `
-Type String -ValueName 'NtpServer' -Value $TimeServer | out-null

Set-GPPrefRegistryValue -Name $GPOName -Action Update -Context Computer `
-Key 'HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters' `
-Type String -ValueName 'Type' -Value 'NTP' | out-null

#link the new GPO to the Domain Controllers OU
New-GPLink -Name $GPOName `
-Target $TargetOU | out-null

My Group Policy Management Console (GPMC) before running the script is shown in Figure 1 showing no WMI Filters exist.

The script is processed and then I ran the Get-GPO cmdlet to verify the GPO was created (Figure 2).

After a refresh, a look back in the GPMC (Figure 3) showing the new WMI Filter and GPO.

Selecting the new WMI Filter in the GPMC shows all the settings are correct: Filter Name, Description, and Query as shown in Figure 4.

Another look in the GPMC at the Domain Controllers OU shows the new GPO is linked properly as shown in Figure 5.

And Figure 6 shows all the registry keys are set properly.

The current registry keys are shown in Figures 7 and 8.

After a GPUPDATE /FORCE, the registry keys are shown in Figures 9 and 10.

What happens on a domain controller that is not the PDCe?  That is shown in Figure 11.  As you can see, the new GPO was denied because of the WMI Filter.

There you go.  Now you can automate creating the Group Policy to set the Forest Root Domain’s PDCe as the authoritative time server for your AD Forest.

You can always find the most current script by going to https://www.carlwebster.com/where-to-get-copies-of-the-documentation-scripts/

Thanks

Webster

In my lab, I created five different WebstersLab.com domains.  Obviously, only one WebstersLab.com domain was powered on at a time.  The first four labs have three domain controllers: LabDC1, LabDC2, and LabDC3.  The fifth lab had an additional LabDC4 DC.  In all five labs, LabDC1 holds all five FSMO roles.

Note: FSMO – Flexible Single-Master Operations, see http://technet.microsoft.com/en-us/library/cc961936.aspx

The following domains were created:

• 2012 with Forest Functional Level (FFL) and Domain Function Level (DFL) set to 2012.
• 2008 R2 with FFL and DFL of 2008 R2.
• 2008 with FFL and DFL of 2008.
• 2003 R2 with FFL and DFL of  2003.
• Mixed with a 2003 DC, 2008 DC, 2008 R2 DC, and a 2012 DC.  FFL and DFL were set to 2003.

All servers in all labs had all Windows Updates as of 05-AUG-2013.

Because I knew that LabDC1 was going to go through several demotion and promotions for this article, all DCs have the following set for their DNS IP settings:

• Primary:               LabDC2
• Secondary:         LabDC3
• Tertiary:               Loopback

Windows Server 2012

How do you find which domain controller has which FSMO role?  From a PowerShell session or Windows Command Prompt, run the following command as shown in Figure 1:

netdom query fsmo

Since LabDC1 holds all five FSMO roles, what happens when it is demoted?

From a PowerShell session on LabDC1, run the following command:

Uninstall-ADDSDomainController -DemoteOperationMasterRole:$true -Force:$true

Note: The DemoteOperationMasterRole:$true indicates that forced demotion should continue even if an operations master role is discovered on the domain controller from which AD DS is being removed.

Enter and confirm the password for the Local Administrator account and the demotion process runs as shown in Figure 2.

Once the demoted domain controller restarts (or from one of the remaining DCs), from a PowerShell session or Windows Command Prompt, rerun the netdom query fsmo command as shown in Figure 3.

Windows Server 2008 R2

How do you find which domain controller has which FSMO role?  From a PowerShell session or Windows Command Prompt, run the following command as shown in Figure 4:

netdom query fsmo

Since LabDC1 holds all five FSMO roles, what happens when it is demoted?

Click Start, Run type in dcpromo, and press Enter (Figure 5).

Proceed through the Active Directory Domain Services Installation Wizard and click Next (Figure 6).

Once the demoted domain controller restarts (or from one of the remaining DCs), from a PowerShell session or Windows Command Prompt, rerun the netdom query fsmo command as shown in Figure 7.

Windows Server 2008

How do you find which domain controller has which FSMO role?  From a Windows Command Prompt, run the following command as shown in Figure 8:

netdom query fsmo

Since LabDC1 holds all five FSMO roles, what happens when it is demoted?

Click Start, Run type in dcpromo, and press Enter (Figure 9).

Proceed through the Active Directory Domain Services Installation Wizard and click Next (Figure 10).

Once the demoted domain controller restarts (or from one of the remaining DCs), from a Windows Command Prompt, rerun the netdom query fsmo command as shown in Figure 11.

Windows Server 2003 R2

How do you find which domain controller has which FSMO role?  First, the Windows Support Tools must be installed.  Then from a Windows Command Prompt, run the following command as shown in Figure 12:

netdom query fsmo

Since LabDC1 holds all five FSMO roles, what happens when it is demoted?

Click Start, Run type in dcpromo, and press Enter (Figure 13).

Proceed through the Active Directory Installation Wizard and click Next (Figure 14).

Once the demoted domain controller restarts (or from one of the remaining DCs), from a Windows Command Prompt, rerun the netdom query fsmo command as shown in Figure 15.

One More Just for the Heck of it

Just out of my own curiosity, I wanted to see what would happen in a mixed environment with four different Windows Server operating systems with each set as a domain controller.

LabDC1 running Windows Server 2003 R2 was installed first and the DFL and FFL were upgraded to Windows Server 2003.  Because LabDC1 was installed first, it is the Forest Root domain controller and holds all five FSMO roles as shown in the screen capture from LabDC4 (Figure 16).

The remaining domain controllers were installed in the following order:

• LabDC2 (Windows Server 2008)
• LabDC3 (Windows Server 2008 R2)
• LabDC4 (Windows Server 2012)

Since LabDC1 holds all five FSMO roles, what happens when it is demoted?

Click Start, Run type in dcpromo, and press Enter (Figure 17).

Proceed through the Active Directory Installation Wizard and click Next (Figure 18).

Once the demoted domain controller restarts (or from one of the remaining DCs), from a Windows Command Prompt, rerun the netdom query fsmo command as shown in Figure 19.

I was hoping the FSMO roles would wind up on LabDC4 since it is the most current Windows Server version.

Conclusion

There are a few points I want to make.

1. If all your DCs and your Active Directory (AD) are healthy, a demotion of a DC that holds any or all FSMO roles should automatically transfer the FSMO roles to another DC.
2. You have NO control over which DC receives the FSMO role or roles held by the demoted DC.
3. If the demoted DC was running AD-Integrated DNS and any computers were pointing to it for DNS, those computers need to be reconfigured to point to another DNS server.
4. It is really best to transfer any FSMO roles before demoting a DC.

What happens if there are issues with one or more DCs and or there are issues with AD?  The following error message is returned during the demotion process:

“The directory service is missing mandatory configuration information, and is unable to determine the ownership of floating single-master operation roles.”

If you receive this error message, Philip Elder SBS MVP has an article with several links to help get the underlying issue resolved.  Please see AD DS Operation Failed – directory service is missing mandatory configuration – Event ID 2091 – FSMO Role Broken.

I know my labs were very simple and it is rare to find a very simple AD environment or one that is perfectly healthy so it is possible there may be issues involved in the process.  My point in spending 25 hours building all these labs and writing this article is to prove that an automatic transfer of FSMO roles works all the way back to Windows Server 2003 and if AD is healthy, the process just works.

My answer to the person who asked the question at Briforum was that if everything works as it should when a DC is demoted any FSMO roles it held should be transferred to another DC.

Thanks

Webster

I have absolutely no idea if PVS7 running on Server 2012 will work with a gMSA or not.  Citrix says it should work, but the articles I have read from Microsoft make it seem like the application must be written to support and work with gMSA.  You will find out at the same time I do whether this experiment will work.

To get more information on gMSA, please read this TechNet article.

There are three requirements to use a gMSA:

1. At least one Windows Server 2012 Domain Controller.
2. A Windows Server 2012 or Windows 8 computer with the ActiveDirectory PowerShell module to create/manage the gMSA.
3. A Windows Server 2012 or Windows 8 domain member to run/use the gMSA.

I installed a Server 2012 Domain Controller into my lab environment, using it to create and manage the gMSA.

Step 1: Create the Key Distribution Services (KDS) Root Key

The KDS Root Key is used by the KDS service on the domain controller to generate passwords.  On my Server 2012 Domain Controller, I will run from an elevated PowerShell session:

Add-KDSRootKey –EffectiveImmediately

The TechNet article says the key can take up to 10 hours to replicate and take effect.  Since I only have one Server 2012 domain controller and two domain controllers in my lab, I am not worried about the replication time.  By the way, it took almost one hour in my lab before the key was usable!

Step 2: Create and configure the gMSA

I am going to create a Security Group containing my two PVS7 servers.  This security group will contain the computer accounts allowed to use the gMSA.

Next, my two PVS7 servers need to be restarted to know they were added to the security group.

From the elevated PowerShell session on my Server 2012 domain controller, I run:

New-ADServiceAccount –Name PVS7StreamSOAP –DNSHostName PVS7StreamSOAP.websterslab.com –PrincipalsAllowedToRetrieveManagedPassword “PVS7gMSAGroup”

Note: The Name is a NetBIOS name that must not be more than 15 characters.

The gMSA now appears in the Managed Service Accounts OU in Active Directory Users and Computers.

Step3: Configure the gMSA on the PVS7 host

Note: The following requires the Active Directory module for Windows PowerShell to be installed on the PVS7 host.  It can be uninstalled after the test is successful.

From an elevated PowerShell session on the PVS7 server, I will run the following two cmdlets:

Install-AdServiceAccount PVS7StreamSOAP

Test-AdServiceAccount PVS7StreamSOAP

The Test-AdServiceAccount should return True.  If it returns False, a verbose error message should be included.

Now for the time of truth.  Is this going to work in PVS7 or not.  Start the Provisioning Services Configuration Wizard and go to the User account screen.  The TechNet article says the trick is to use a “$” after the gMSA and leave the password blank.

Let’s see what happens when I click Next?????

What do you know, it let me continue, but we are not done yet.

DOH!!!  I guess PVS7 will NOT work with Server 2012’s Group Managed service Accounts after all!  Total Bummer.

Citrix should fix this pronto.  Actually, this should have been in PVS7 from the initial design for Server 2012 support.  gMSA offers several features that would be very useful in a PVS implementation.  Too bad Citrix doesn’t support gMSA at this time.  I hope this gets fixed fast.

Thanks

Webster