extremesanity.com

Looking at this article: http://blogs.technet.com/b/srd/archive/2014/05/13/ms14-025-an-update-for-group-policy-preferences.aspx

I grabbed the check script from here (bottom of the page) http://support.microsoft.com/kb/2962486

and ran it on my domain controller.  The script immediately gave me the error “cannot bind to argument to parameter ‘path’ because it is null”.

Apparently this is an uncaught exception when no XML files exist in the path subfolders.  It appears that ONLY group policy preferences are stored in XML, and this XML file will only show up if group policy preferences are implemented, meaning if you don’t have XML files in %windir%\SYSVOL\domain then you are not affected by this patch.  Group policies themselves appear to be stored as INF and other types.

I wanted to create a quick test lab so I spun up a copy of a virtualized domain controller into an isolated network. The domain controller came up in a failed state with DNS and Active Directory non-functional.

Apparently in a multi domain controller network it is a requirement that the domain controller be able to sync with other domain controllers/role masters in order to function.

Because this was the only domain controller in the network, and I wanted to get the test network up quickly, I performed the following workarounds:

(Thanks to user zabo2012 on the veeam forums at http://forums.veeam.com/vmware-vsphere-f24/restoring-2012-domain-controller-vm-t18629.html for the awesome instructions)

boot the machine up in dsrm ( bcdedit /set safeboot dsrepair )

log in with ds repair mode password .\Administrator

run the bcdedit command to set and remove dsrepair mode ( bcdedit /deletevalue safeboot )

net stop ntfrs

open regedit and

Open Regedit
Browse to the following extension: HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Add the following dword (32 bit) value: Repl Perform Initial Synchronizations
And leave this set to 0.
http://www.veeam.com/kb_articles.html/kb1280
then

open regedit and expand: hklm\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup
Set the burflags to d2 (sometimes you will have to use d4, but only do this in isolated network or it will overwrite other DC’s during replication)
http://www.veeam.com/kb_articles.html/kb1278

reboot

Edit:

I noticed that although I was able to get other servers to authenticate off the DC after doing the above, I wasn’t able to access AD Users and Computers on the DC itself.

Seizing the roles from the other DCs (that are not available in the isolated test lab) fixed this.  To seize the other domain controller FSMO roles:

ntdsutil
roles
connections
connect to server <dns name of local dc server>
quit

seize schema master
seize naming master
seize rid master
seize PDC
seize infrastructure master

quit
quit

After seizing roles I now see the expected information in AD Users and Computers

Edit 2:

I continued to have problems with an Exchange server that was in the same test lab as the isolated domain controller so I made a few more changes:

I performed a metadata cleanup, removing all the domain controllers that were not in the isolated lab environment, using the GUI > http://technet.microsoft.com/en-us/library/cc816907%28v=ws.10%29.aspx#bkmk_graphical

I then set the burflag to d4 (below) and restarted the domain controller.  After that exchange was working correctly.

open regedit and expand: hklm\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup
Set the burflags to d4
http://www.veeam.com/kb_articles.html/kb1278

In some situations an error will be thrown when trying to assign “null” to a parameter for a query.  In this situation, assign “DBNull.Value” to the parameter.

Example:

thisCommand.Parameters.Add(“@datLastCalExpr”, System.Data.SqlDbType.DateTime).Value = DBNull.Value;