Cloning Virtual Domain Controllers

A new feature of Windows Server 2012 is the cloning of Domain Controllers. This is a rapid way to deploy new Domain Controllers in virtual machine forms. The detailed step-by-step is outlined in Virtual Domain Controller Cloning in Windows Server 2012. I won't attempt to repeat all the details. Hence, I would summarize the steps for easy reference later.

Prerequisite Check:

1. The hypervisor must support VM-GenerationID. Hyper-V running on Windows Server 2012/Windows 8 supports this feature and so do VMWare vSphere 5.x.  
2. The source virtual DC must be running Windows Server 2012. 
3. The PDC emulator role holder must be online and available to the cloned DC and must be running Windows Server 2012.

Step 1: Add source DC VM into "Clonable Domain Controllers" Security Group

Step 2: Check for applications and determine whether they should be cloned by running "Get-ADDCCloningExcludedApplicationList" cmdlet. If application is not supported for cloning, uninstall it. Otherwise, add the application to the inclusion list (CustomDCCloneAllowList.xml). The list can be generated with the same cmdlet with "-GenerateXML" option.

Step 3: Run "New-ADDCCloneConfigFile" cmdlet on source VM to run a list of prerequisite checks as mentioned above. It would also generate "DCCloneConfig.xml" file that contains a list of settings to be applied to the cloned DC, including network settings, DNS, WINS, AD site name, new DC name etc. The xml file is contained at the "%Systemroot%\NTDS" folder. These new settings can be specified with the same cmdlet input with the necessary options. For example:

New-ADDCCloneConfigFile -IPv4Address 10.2.1.10 -IPv4DefaultGateway 10.2.1.1 -IPv4SubnetMask 255.255.255.0 -IPv4DNSResolver 10.1.1.10,10.1.1.11 -Static -SiteName CORPDR

Step 4: Shut down the source VM and export it out using "Export-VM" cmdlet e.g. Export-VM -name sourceDC -Path D:\ClonedDC.

Step 5: Import the VM by running "Import-VM" cmdlet e.g. Import-VM –Path {VM XML Path} –Copy –GenerateNewId –VhdDestinationPath D:\ClonedDC. You can also rename the new VM using Hyper-V manager. Start the newly cloned VM.

New MS2012 Dynamic Access Control (DAC) for BYOD?

One major new feature in Windows Server 2012 is the introduction of Dynamic Access Control (DAC). At the first glance, it seems to be replacing or enhancing the traditional NTFS ACL. In fact, it's neither. In traditional file shares, the access control is typically controlled by both share permissions and NTFS ACL. DAC is an add-on feature on top of these existing access control mechanisms. For example, you may allow a group of finance executives to access a sensitive finance file share from their managed workstations. But what if the corporate policy forbid them for doing so when they are accessing from mobile or personal devices? This is where DAC comes in.

In DAC, you can create access rule that is expressed in "if-then" statement. Using the same example, you may express the policy as "If the user clearance is high and the user department is finance; and accessed from a managed finance device, then the user can access finance files and folders classified as having high business impact". See below illustration:

I won't attempt to go through the detailed step-by-step in implementing DAC, as there is already a dedicated blog for DAC at http://www.dynamic-access-control.com/. I would just summarise the steps as follows:

On a Windows Server 2012 domain controller:

1. First, ensure that the domain functional level is Windows Server 2012, as expanded Kerberos with claim-based information is required. Enable "KDC support for claims, compound authentication and Kerberos armoring" using Group Policy on Domain Controllers OU.
2. Define the user and device claims types using the new "Active Directory Administrative Center (ADAC)" under "DAC - New Claim Types". For example, you may like to define the new User.Department and Device.Managed attributes. You may even provide a list of values such as "Engineering", "Finance", "IT" for User.Department. 
3. Define the new Resource Properties for the files and folders using the same ADAC console. In this case, you may want to define Resource.Department and Resource.Impact. Add the resource properties to the pre-defined "Global Resource Property List".
4. Create a new central access rule e.g. using earlier expression as example.
5. Create a new central access policy and add the central access rule into it. This new central access policy has to be enforced by the file servers mentioned later.
6. Tag the user account objects using attribute editor in "AD Computers and Users" console e.g. department etc.
7. You may also want to tag the computer attributes. Do note that Windows 8 is required for claim-based devices.

On a file server running Windows Server 2012:

• The earlier steps have created Central Access Policy on AD. However, the enforcement has to be performed on individual file server.
• Add new Windows Feature "File Share Resource Manager" using Server Manager or Powershell
• Run PS cmdlet "Update-FSRMClassificationPropertyDefinition" to  synchronizes the classification property definitions on the file server with the Resource property definitions on AD
• You may perform Manual Classification by setting the resource property (Classification tab) on the file and folder properties directly.

• Alternatively, you may perform "Automatic Classification" by creating Classification Rules on "File Server Resource Manager". You may set the rules to be run at fixed interval.

• After file tagging and classification, deploy and enforce the earlier created central access policy on the file server. You can find a new "Central Policy" tab on the "Advanced Security Settings" of the share folder

• You may also test-run the deployment using the "Effective Access" tab (left of Central Policy tab as above)

As for rolling out DAC incrementally, this is what Microsoft would recommend in summary:

Reference: WS2012 Dynamic Access Control Tips and Overview

Moving WSUS Content Store

The content of WSUS is growing exponentially and the storage is nearly full. To move the existing content to a bigger LUN, Wsusutil.exe is the program. To execute the move, prepare the new destination folder and use this command:
Wsusutil.exe movecontent {new location} {log file}  [-skipcopy]

Use the -skipcopy option, if you do not wish to copy existing content over. For example, if the new location is at D:\content, the command should be:
Wsusutil.exe movecontent D:\Content D:\move.log

For Windows Server 2008, the location of Wsusutil should be at "C:\Program Files\Microsoft Windows Server Update Services\Tools". For Windows Server 2012, you should be able to find the executable at "C:\Program Files\Update Services\Tools".