Hi AskPFEPlat readers. Tom Moser here. A question I get on a pretty frequent basis from my larger, multi-forest enterprise customers is:

“Do I need to add subnets from Forest A to Forest B so that clients find the correct DC across the trust?”

And here’s how I try to answer that question, usually with a lot of words, a little white boarding, and a lot of pointing. I thought, “this needs pictures…” so here you go.

If you’re in a hurry to get back to /r/sysadmin, the short answer is no. If you want to know why, keep reading. Then maybe cross post this for me there.

*** Point of Clarification ***

This post is about the a scenario where the subnets in the two forests do not overlap (i.e., client’s IP address from forest A is not covered by any subnet in forest B). This would typically occur in resource forest scenarios with separate networks. For example: federating via trust with Microsoft online services or a trust between a corporate forest and a perimeter forest. Everything you’re about to read below assumes that the client IP from Forest A is not covered by any subnet in Forest B.

In cases where the two forests have conflicting subnets (for example, 10.1.1.0/24 means site “Detroit” in Forest A, but means site “Siberia” in Forest B), there are additional considerations. We will cover these in a later post.

Read the rest of the article

The following AD groups are considered “local” to the Domain Controllers:

• Administrators
• Backup Operators
• Print Operators
• Server Operators

What’s interesting is that these groups are the local groups from the first DC promoted for the new domain, so the SID matches.

Mark Russinovich states this scenario well in his blog:

As I said earlier, there’s one exception to rule, and that’s DCs themselves. Every Domain has a unique Domain SID that’s the machine SID of the system that became the Domain’s first DC, and all machine SIDs for the Domain’s DCs match the Domain SID. So in some sense, that’s a case where machine SIDs do get referenced by other computers. That means that Domain member computers cannot have the same machine SID as that of the DCs and therefore Domain. However, like member computers, each DC also has a computer account in the Domain, and that’s the identity they have when they authenticate to remote systems.

The really interesting scenario is one where Company A owns Company B & Company C and while the IT shop keeps the domains for each domain separated, they build all the DCs from the same image (but don’t sysprep or change the SID meaning the first DC for each domain has the same machine SID and thus the same domain SID). Company A sells off Company B & Company C. Later on Company B & Company C merge and want to set up AD trusts between them. They can’t because the domains in both Company B & Company C have the same SID and a trust can’t reference its own SID!

Here’s the code:
 

ANR enables you to find a user when you have some information about a user, but don’t know exactly to which attribute that data corresponds. For example, if you know the user has “Thor” somewhere, but don’t know exactly what the SAMAccountName is (or DN, SID, name, etc).  Submitting an ANR search will query the AD attributes flagged for ANR (attributes must be indexed) and replies with the results (may be more than one user found).

Windows Server 2008 checks the following attributes for ANR queries:

• displayName
• givenName
• legacyExchangeDN
• msDS-AdditionalSamAccountName
• msDS-PhoneticCompanyName
• msDS-PhoneticDepartment
• msDS-PhoneticDisplayName
• msDS-PhoneticFirstName
• msDS-PhoneticLastName
• physicalDeliveryOfficeName
• proxyAddresses
• Name
• sAMAccountName
• sn

Since ANR is an LDAP-specific feature with AD, you have to use a LDAP filter to get it.

Using the Microsoft AD cmdlets included in Windows Server 2008 R2, Get-ADObject performs an ANR search:

For Example:
Get-ADObject -LDAPFilter { (&(ObjectClass=User)(ANR=Thor) }

The Quest AD cmdlets support ANR natively (of course they do!).

Reference Articles:

• MSDN: Ambiguous Name Resolution (ANR)
• Windows: The Underestimated Ambiguous Name Resolution (ANR) Search in Active Directory

We’ve been talking to a lot of people about deploying integration services (integration components) lately.  As it turns out, they’re pretty easy to patch offline with existing Hyper-V tools.

First, why would you update integration services on a not-running (offline) VM?

Offline VM servicing is valuable for VM templates places that create new VMs frequently since it allows you to keep VM templates up-to-date.  While this post targets exclusively integration service updates, the same update approach applies to many updates as well as any configurations specific to the environment.  Keeping the VM images fully up to date and configured before they are deployed saves significant setup time and support every time a new VM is created.

Here is a detailed write-up about deploying and updating integration services on an offline VM – both VHD/VHDX – using out of box PowerShell tools and a cab (cabinet) file that comes bundled with Server 2008 or later Hyper-V hosts.

Read More

Read all about it here.

If you find that you are greeted with a command prompt after logging on and wish to have a full GUI, run the following commands to switch from “Server Core” mode to full GUI.

Powershell
Install-Module ServerManager
Install-WindowsFeature Server-GUI-Shell -Restart

References:

• Install & Deploy Windows Server 2012
• Installing Windows Server 2012

Read the blog post: MailBag: RODCs – krbtgt_#####, Orphans, and Load Balancing RODC Connection Objects

Here are the highlights:

• Plan for the peak busy period of the day. It is recommended to look at this in either 30 minute or hour intervals. Anything greater may hide the actual peaks and anything less may be distorted by “transient spikes.”
• CPU Sizing:  1 modern physical core per 1,000 users (authentication).
• RAM Sizing:  2-4 GB for OS + size of NTDS.dit + size of SYSVOL.

Also, don’t forget to perform core calculations to ensure appropriate capacity for Exchange (8:1 ratio for Exchange cores to GC cores) and other applications.

I typically recommend that at least 1 DC is on physical hardware in each domain – preferably 1 physical DC per domain in each datacenter.  DCs should be spread across virtual hosts as much as possible to provide redundancy and ensure there’s DC capacity for virtual clients and application servers.

Powershell version 3.0 has 135 commandlets, adding 59 new commandlets covering AD Central Access Policy, AD Replication, AD Claims, and more.

Here’s the list of all Active Directory commandlets in Powershell v3:

• Add-ADCentralAccessPolicyMember 
• Add-ADComputerServiceAccount
• Add-ADDomainControllerPasswordReplicationPolicy
• Add-ADFineGrainedPasswordPolicySubject
• Add-ADGroupMember
• Add-ADPrincipalGroupMembership
• Add-ADResourcePropertyListMember
• Clear-ADAccountExpiration
• Clear-ADClaimTransformLink  
• Disable-ADAccount
• Disable-ADOptionalFeature
• Enable-ADAccount
• Enable-ADOptionalFeature
• Get-ADAccountAuthorizationGroup
• Get-ADAccountResultantPasswordReplicationPolicy
• Get-ADCentralAccessPolicy                                     
• Get-ADCentralAccessRule                                       
• Get-ADClaimTransformPolicy                                    
• Get-ADClaimType 
• Get-ADComputer
• Get-ADComputerServiceAccount
• Get-ADDCCloningExcludedApplicationList
• Get-ADDefaultDomainPasswordPolicy
• Get-ADDomain
• Get-ADDomainController
• Get-ADDomainControllerPasswordReplicationPolicy
• Get-ADDomainControllerPasswordReplicationPolicyUsage
• Get-ADFineGrainedPasswordPolicy
• Get-ADFineGrainedPasswordPolicySubject
• Get-ADForest
• Get-ADGroup
• Get-ADGroupMember
• Get-ADObject
• Get-ADOptionalFeature
• Get-ADOrganizationalUnit
• Get-ADPrincipalGroupMembership
• Get-ADReplicationAttributeMetadata
• Get-ADReplicationConnection
• Get-ADReplicationFailure
• Get-ADReplicationPartnerMetadata
• Get-ADReplicationQueueOperation
• Get-ADReplicationSite
• Get-ADReplicationSiteLink
• Get-ADReplicationSiteLinkBridge
• Get-ADReplicationSubnet
• Get-ADReplicationUpToDatenessVectorTable
• Get-ADResourceProperty
• Get-ADResourcePropertyList
• Get-ADResourcePropertyValueType
• Get-ADRootDSE
• Get-ADServiceAccount
• Get-ADTrust
• Get-ADUser
• Get-ADUserResultantPasswordPolicy
• Install-ADServiceAccount
• Move-ADDirectoryServer
• Move-ADDirectoryServerOperationMasterRole
• Move-ADObject
• New-ADCentralAccessPolicy
• New-ADCentralAccessRule
• New-ADClaimTransformPolicy
• New-ADClaimType
• New-ADComputer
• New-ADDCCloneConfigFile
• New-ADFineGrainedPasswordPolicy
• New-ADGroup
• New-ADObject
• New-ADOrganizationalUnit
• New-ADReplicationSite
• New-ADReplicationSiteLink
• New-ADReplicationSiteLinkBridge
• New-ADReplicationSubnet
• New-ADResourceProperty
• New-ADResourcePropertyList
• New-ADServiceAccount
• New-ADUser
• Remove-ADCentralAccessPolicy
• Remove-ADCentralAccessPolicyMember
• Remove-ADCentralAccessRule
• Remove-ADClaimTransformPolicy
• Remove-ADClaimType
• Remove-ADComputer
• Remove-ADComputerServiceAccount
• Remove-ADDomainControllerPasswordReplicationPolicy
• Remove-ADFineGrainedPasswordPolicy
• Remove-ADFineGrainedPasswordPolicySubject
• Remove-ADGroup
• Remove-ADGroupMember
• Remove-ADObject
• Remove-ADOrganizationalUnit
• Remove-ADPrincipalGroupMembership
• Remove-ADReplicationSite
• Remove-ADReplicationSiteLink
• Remove-ADReplicationSiteLinkBridge
• Remove-ADReplicationSubnet
• Remove-ADResourceProperty
• Remove-ADResourcePropertyList
• Remove-ADResourcePropertyListMember
• Remove-ADServiceAccount
• Remove-ADUser
• Rename-ADObject
• Reset-ADServiceAccountPassword
• Restore-ADObject
• Search-ADAccount
• Set-ADAccountControl
• Set-ADAccountExpiration
• Set-ADAccountPassword
• Set-ADCentralAccessPolicy
• Set-ADCentralAccessRule
• Set-ADClaimTransformLink
• Set-ADClaimTransformPolicy
• Set-ADClaimType
• Set-ADComputer
• Set-ADDefaultDomainPasswordPolicy
• Set-ADDomain
• Set-ADDomainMode
• Set-ADFineGrainedPasswordPolicy
• Set-ADForest
• Set-ADForestMode
• Set-ADGroup
• Set-ADObject
• Set-ADOrganizationalUnit
• Set-ADReplicationConnection
• Set-ADReplicationSite
• Set-ADReplicationSiteLink
• Set-ADReplicationSiteLinkBridge
• Set-ADReplicationSubnet
• Set-ADResourceProperty
• Set-ADResourcePropertyList
• Set-ADServiceAccount
• Set-ADUser
• Sync-ADObject
• Test-ADServiceAccount
• Uninstall-ADServiceAccount
• Unlock-ADAccount

The AD commandlets new to Powershell v3 are bolded.

Import-module activedirectory ;
(Get-ADObject “CN=MCLABDC01,OU=Domain Controllers,DC=MCLAB,DC=net” -server mclabdc01.mclab.net -property msds-generationid).’msds-generationid’

Here’s what I posted to the TechNet Script Center:

Ever wonder who has full admin rights to your domain?

The script discovers the default Administrators group by looking up the group by its well-known SID (S-1-5-32-544) in the domain and enumerates all user and group members. The expanded membership of the default Administrators group in the domain is what I call “Domain-Level Admins” or DLAs. Domain Admins are members of the Domain Admins group in the domain, but there any member of the Administrators group has full admin rights to the Active Directory domain and the associated Domain Controllers.

The script provides the expanded group membership for each of the group members.

Here’s the output example:

DOMAIN-LEVEL ADMINS:
====================
Discovered 3 Domain-Level Admins (DLAs) with admin rights provided by 6 groups:

Administrators Membership (4 Members):
—————————————–
Administrator (CN=Administrator,CN=Users,DC=MCLAB,DC=net)
GROUP: Domain Admins (CN=Domain Admins,CN=Users,DC=MCLAB,DC=net)
GROUP: Enterprise Admins (CN=Enterprise Admins,CN=Users,DC=MCLAB,DC=net)
GROUP: GroupTest01 (CN=GroupTest01,OU=Test,DC=MCLAB,DC=net)

GroupTest03 Membership (0 Members):
—————————————–
No members

GroupTest02 Membership (0 Members):
—————————————–
No members

GroupTest01 Membership (0 Members):
—————————————–
No members

Domain Admins Membership (3 Members):
—————————————–
ADMIN (CN=ADMIN,OU=Admins,DC=MCLAB,DC=net)
ADMIN2 (CN=ADMIN2,OU=Admins,DC=MCLAB,DC=net)
Administrator (CN=Administrator,CN=Users,DC=MCLAB,DC=net)

Enterprise Admins Membership (1 Members):
—————————————–
ADMIN (CN=ADMIN,OU=Admins,DC=MCLAB,DC=net)

Script started processing at 03/01/2013 22:18:29 and completed at 03/01/2013 22:18:30.

This script gathers a variety of information from the Active Directory environment and provides a final report of the configuration. Running this provides a great snapshot of what is in AD and where it is located.  Data collected includes: Forest & Domain info, AD & Schema versions, AD setup (instantiation) date, AD tombstone lifetime, the last time each partition was backed up, the percentage of RIDs used and percentage of RIDs available, a count of domain GPOs (for current domain), count of all sites and list of DCs by site, DC count total and by OS version, and statistics by object type for users, groups, and computers (workstations and servers).

NOTE: This script leverages the PowerShell v2.0 Active Directory & Group Policy commandlets to work properly.  On Windows Server 2008 R2, install the Active Directory Powershell commandlets by running:
“powershell import-module servermanager ; add-windowsfeature rsat-ad-powershell”  

Here are the major components of the script:

• Get Active Directory Forest & Domain Info
• Get AD & Exchange Schema Version Number
• Get AD Instantiation Date
• Get Domain Password Policy
• Get Tombstone Setting
• Get AD Last Backup Date
• Get Domain RID Info
• Get AD Object Count
• Get AD LastLogonTimeStamp Replication Setting
• Get Domain GPO Stats
• Get AD Site Data
• Get Domain Controller Information
• User Statistics
• Get AD Group (Global, Universal, Distribution, Security, etc) Statistics
• Get AD Computer (Workstations & Servers) Statistics

The final report looks like this:

TODAY’S REPORT
==============
Generated: 02/27/2013 21:36:29
—————————–

ACTIVE DIRECTORY DETAILS:
————————-
Active Directory Forest Name : MCLab.net
Active Directory Domains in the Forest: MCLab.net
Active Directory Current Domain Name : MCLAB

Active Directory Instatiation Date: 03/17/2010 00:58:06

The AD Schema Version is 56 which is Windows Server 2012 Forest Functional Mode
The Exchange Schema Version is 14732 which is Exchange 2010 SP2 Schema

Active Directory’s Tombstone Lifetime is set to 180 days
The LastLogonTimestamp attribute is configured to replicate every 1 days.
This affects the accuracy of the User & Computer logon stats below (they may be off by ~ 1 days).

Domain Relative IDentifiers (RIDs) determine how many Security IDentifiers (SIDs) can be created.
RIDs Issued: 51600 (0.00 % of total)
RIDs Remaining: 1073690223 (100.00 % of total)

ACTIVE DIRECTORY BACKUP STATUS:
——————————-
DC=MCLAB,DC=net last backed up on 06/16/2011 15:00:31
CN=Configuration,DC=MCLAB,DC=net last backed up on 06/16/2011 15:00:31
CN=Schema,CN=Configuration,DC=MCLAB,DC=net last backed up on 06/16/2011 15:00:31
DC=DomainDnsZones,DC=MCLAB,DC=net last backed up on 06/16/2011 15:00:31
DC=ForestDnsZones,DC=MCLAB,DC=net last backed up on 06/16/20 11 15:00:31

ACTIVE DIRECTORY OBJECT SNAPSHOT:
———————————-
Active Directory Schema Partition Stats:
4329 objects in CN=Schema,CN=Configuration,DC=MCLAB,DC=net

Active Directory Configuration Partition Stats:
4329 objects in CN=Configuration,DC=MCLAB,DC=net
9 Deleted objects in CN=Configuration,DC=MCLAB,DC=net
0 Recycled objects in CN=Configuration,DC=MCLAB,DC=net

Active Directory Domain Partition Stats:
2149 objects in DC=MCLAB,DC=net
13 Deleted objects in DC=MCLAB,DC=net
0 Recycled objects in DC=MCLAB,DC=net

There are 12 Active Directory Sites in the AD Forest.
There are 72 GPOs in the current Active Directory Domain.

ACTIVE DIRECTORY FSMOs:
———————–
AD Forest Naming Master : R2D2.MCLab.net
AD Forest Schema Master : R2D2.MCLab.net
AD Domain PDC Master : R2D2.MCLab.net
AD Domain RID Master : R2D2.MCLab.net
AD Domain Infrastructure Master : R2D2.MCLab.net

DOMAIN CONTROLLER INFORMATION:
——————————
Out of the 3 DCs in MCLab.net :
0 are RODCs & 3 are writable DCs
0 are running Windows Server 2012
0 are running Windows Server 2008 R2 SP1
2 are running Windows Server 2008 R2 (No Service Pack)
2 are running Windows Server 2008 (Any Service Pack)
0 are running Windows Server 2003 R2 (Any Service Pack)
0 are running Windows Server 2003 (Any Service Pack)
0 are running Windows 2000 Server (Any Service Pack)

DOMAIN USER STATISTICS:
———————–
There are 1008 user objects discovered in MCLab.net
There are 24 Enabled users and there are 984 Disabled users in MCLab.net
There are 24 users identified as Inactive (with passwords older than 90 days in MCLab.net
There are 11 Enabled Service accounts in MCLab.net (out of a total 11 Service accounts)
There are 8 users in MCLab.net with an Exchange Mailbox.
There are 8 Enabled users in MCLab.net with an Exchange Mailbox.
Out of 24 Enabled users in MCLab.net only 6 have logged on in the last 30 days (there may be up to a 14 day margin of error for this count)
Out of 24 Enabled users in MCLab.net only 6 have logged on in the last 45 days
Out of 24 Enabled users in MCLab.net only 6 have logged on in the last 60 days
Out of 24 Enabled users in MCLab.net only 7 have logged on in the last 90 days
Out of 24 Enabled users in MCLab.net only 7 have logged on in the last 120 days
Out of 24 Enabled users in MCLab.net only 7 have logged on in the last 180 days
Out of All 1008 users in MCLab.net 978 have NEVER logged on (no logon date associated with account)
6 Enabled users logged in within the last week
2 Enabled users logged in yesterday
4 Enabled users logged in today (so far)
0 Enabled users are currently locked out

DOMAIN GROUP STATISTICS:
————————
There are 55 Universal groups in AD (37.93 % of all groups)
There are 62 Global groups in AD (42.76 % of all groups)
There are 28 Domain Local groups in AD (19.31 % of all groups)
There are 133 Security groups in AD (91.72 % of all groups)
There are 133 Mail-Enabled Security groups in AD (0.00 % of all groups)
There are 12 Distribution groups in AD (8.28 % of all groups)
There are 0 Distribution groups that are not Universal groups in AD (0.00 % of all groups)

DOMAIN COMPUTER STATISTICS:
—————————
There are 473 Computers discovered in MCLab.net
There are 471 Enabled Computers and there are 2 Disabled Computers in MCLab.net
There are 461 Computers identified as Inactive (with passwords older than 90 days in MCLab.net

WORKSTATIONS:
After filtering server objects, There are 10 Windows workstations discovered in MCLab.net
There are 8 Enabled Windows workstations discovered in MCLab.net
There are 4 Active Enabled Windows workstations discovered in MCLab.net
There are 0 Active Enabled Windows workstations running Windows XP discovered in MCLab.net
There are 0 Active Enabled Windows workstations running Windows Vista discovered in MCLab.net
There are 3 Active Enabled Windows workstations running Windows 7 discovered in MCLab.net
There are 1 Active Enabled Windows workstations running Windows 8 discovered in MCLab.net
There are 0 enabled workstations that have a blank DNS host name attribute
There are 0 enabled workstations that have a DNS subdomain

SERVERS:
After filtering workstation objects, There are 19 SERVERS discovered in MCLab.net
There are 19 Enabled Windows SERVERS discovered in MCLab.net
There are 0 Active Enabled Windows SERVERS discovered in MCLab.net
There are 18 Active Enabled Windows SERVERS running Windows NT discovered in MCLab.net
There are 0 Active Enabled Windows SERVERS running Windows 2000 discovered in MCLab.net
There are 0 Active Enabled Windows SERVERS running Windows 2003 discovered in MCLab.net
There are 16 Active Enabled Windows SERVERS running Windows 2008 discovered in MCLab.net

View the Active Directory Forest/Domain Configuration Summary & Object Statistics Script

Windows Server 2012 includes a Powershell method for configuring the server with Powershell Web Access.

Here are the configuration Powershell commands:

1.  Install-WindowsFeature WindowsPowerShellWebAccess –IncludeManagementTools
2. Install-PswaWebApplication –WebApplicationName “pswagateway” –UseTestCertificate
3. Add-PswaAuthroizationRule –UserGroupName “MCLAB\Domain Admins” –ComputerGroupName “MCLAB\Domain Controllers”–ConfigurationName Microsoft.powershell
4. After configuration is complete, open a web browser and point it to https://SERVERNAME/pswagateway
5. Log into the site with credentials that are members of group used in step 3.

Upon successful logon, a Powershell console appears in the browser.

For more information, read this TechNet article:
Want Remote PowerShell Management from your browser? See how PowerShell Web Access in Windows Server 2012 may help…

There are major changes to the promotion process which integrate the process. This simplified process includes:

• AD DS role deployment is now part of the new Server Manager architecture and allows remote installation.
• The AD DS deployment and configuration engine is now Windows PowerShell, even when using a graphical setup.
• Promotion now includes prerequisite checking that validates forest and domain readiness for the new domain controller, lowering the chance of failed promotions.
• The Windows Server 2012 forest functional level does not implement new features and domain functional level is required only for a subset of new Kerberos features, relieving administrators of the frequent need for a homogenous domain controller environment.

NOTE: The new “DCPromo” GUI takes longer than before since it performs many more checks than in the past. Since the GUI provides the PowerShell script code, it’s a great idea to script the promotion of all new 2012 DCs.

Install the Active Directory Domain Services (ADDS) role:

1. Install the role “Active Directory Domain Services (ADDS)” on the target server (local or remote).
2. Check the Restart checkbox.
3. Click on Export Configuration Settings to get the Powershell command line equivalent.

Powershell command:

Add-WindowsFeature AD-Domain-Services

Promote the server to DC:

1. Run the Active Directory Domain Services Configuration Wizard.
2. Select Add a Domain Controller to an Existing Domain.
3. Select the appropriate DC options and enter the DSRM password.
4. Change any options on the following pages as appropriate.
5. Click on View Script to view the Powershell script command.
6. Click Install.

Here’s the Powershell script the GUI creates when creating a new forest accepting all defaults:

Import-Module ADDSDeployment
Install-ADDSForest `
-CreateDNSDelegation:$False `
-DatabasePath “c:\Windows\NTDS” `
-DomainMode “Win2012″ `
-DomainName “MCLab.net” `
-DomainNetbiosName “MCLAB” `
-ForestMode “Win2012″ `
-InstallDNS:$true `
-LogPath “C:\Windows\NTDS” `
-NoRebootOnCompletion:$false `
-Sysvolpath “C:\Windows\SYSVOL” `
-Force:$true

Here’s the Powershell script the GUI creates when adding a new Domain Controller to an existing domain accepting all defaults:

Import-Module ADDSDeployment
$SafeModeAdministratorPasswordText = ‘&P@ssw0rd2013&’
$SafeModeAdministratorPassword = ConvertTo-SecureString -AsPlainText $SafeModeAdministratorPasswordText -Force

Install-ADDSDomainController `
-NoGlobalCatalog:$false `
-CreateDNSDelegation:$false `
-Credential (Get-Credential) `
-CriticalReplication:$false `
-DatabasePath “C:\Windows\NTDS” `
-DomainName “mcdevlab.net” `
-InstallDNS:$true `
-LogPath “C:\Windows\NTDS\Logs” `
-SiteName “Default-First-Site-Name” `
-SYSVOLPath “C:\Windows\SYSVOL” `
-Force:$true `
-SafeModeAdministratorPassword $SafeModeAdministratorPassword

Powershell AD commands (with switches):

Install-ADDSDomainController

-ADPrepCredential
-AllowDomainControllerReinstall
-AllowPasswordReplicationAccountName
-ApplicationPartitionsToReplicate
-CreateDnsDelegation
-Credential
-CriticalReplicationOnly
-DatabasePath
-DelegatedAdministratorAccountName
-DenyPasswordReplicationAccountName
-DnsDelegationCredential
-DomainName **
-Force
-InstallationMediaPath
-InstallDns
-LogPath
-MoveInfrastructureOperationMasterRoleIfNecessary
-NoDnsOnNetwork
-NoGlobalCatalog
-NoRebootOnCompletion
-ReadOnlyReplica
-ReplicationSourceDC
-SafeModeAdministratorPassword
-SiteName
-SkipAutoConfigureDns
-SkipPreChecks
-SystemKey
-SysvolPath
-UseExistingAccount
-Confirm
-WhatIf

Install-ADDSForest

-Confirm
-CreateDNSDelegation
-DatabasePath
-DomainMode
-DomainName **
-DomainNetBIOSName **
-DNSDelegationCredential
-ForestMode
-Force
-InstallDNS
-LogPath
-NoDnsOnNetwork
-NoRebootOnCompletion
-SafeModeAdministratorPassword
-SkipAutoConfigureDNS
-SkipPreChecks
-SYSVOLPath
-Whatif

Install-ADDSDomain

-ADPrepCredential
-AllowDomainReinstall
-CreateDnsDelegation
-Credential
-DatabasePath
-DnsDelegationCredential
-DomainMode
-DomainType
-Force
-InstallDns
-LogPath
-NewDomainName **
-NewDomainNetbiosName
-NoDnsOnNetwork
-NoGlobalCatalog
-NoRebootOnCompletion
-ParentDomainName **
-ReplicationSourceDC
-SafeModeAdministratorPassword
-SiteName
-SkipAutoConfigureDns
-SkipPreChecks
-SysvolPath
-Confirm
-WhatIf

** Required Powershell switches

DC Prerequisite Checking:
Domain controller configuration also implements a prerequisite checking phase that evaluates the forest and domain prior to continuing with domain controller promotion. This includes FSMO role availability, user privileges, extended schema compatibility and other requirements. This new design alleviates issues where domain controller promotion starts and then halts midway with a fatal configuration error. This lessens the chance of orphaned domain controller metadata in the forest or a server that incorrectly believes it is a domain controller.

The following tools are installed as part of the DC promotion:

• Active Directory Administrative Center
• Active Directory Domains and Trusts
• Active Directory Module for Windows PowerShell
• Active Directory Sites and Services
• Active Directory Users and Computers
• ADSI Edit
• DNS
• Group Policy Management

NOTE: Running dcpromo /unattend still installs the binaries as before, but produces a warning.

References:

• Step by Step Guide for Setting Up Windows Server 2012 Domain Controller
• Install Active Directory Domain Services (Level 100)
• Install Active Directory Domain Services (Level 200)

Cloning Requirements:

• The hypervisor hosting the virtual DCs must support VM Generation ID.
• The PDC Emulator for the domain containing the source DC must be online and running Windows Server 2012.
• The source DC has to be running Windows Server 2012.

 The PDCE creates the special Cloneable Domain Controllers group and sets its permission on the root of the domain to allow a domain controller to clone itself.

NOTE: The Windows Server 2012 PDCE must be online when cloning due to the following:

The cloning domain controller contacts the PDCE directly using the DRSUAPI RPC protocol, in order to create computer objects for the clone DC.

Windows Server 2012 extends the existing Directory Replication Service (DRS) Remote Protocol (UUID E3514235-4B06-11D1-AB04-00C04FC2DCD2) to include a new RPC method IDL_DRSAddCloneDC (Opnum 28). The IDL_DRSAddCloneDC method creates a new domain controller object by copying attributes from an existing domain controller object.

The states of a domain controller are composed of computer, server, NTDS settings, FRS, DFSR, and connection objects maintained for each domain controller. When duplicating an object, this RPC method replaces all references to the original domain controller with corresponding objects of the new domain controller. The caller must have the control access right DS-Clone-Domain-Controller on the domain naming context.

Use of this new method always requires direct access to the PDC emulator domain controller from the caller.

Because this RPC method is new, your network analysis software requires updated parsers to include fields for the new Opnum 28 in the existing UUID E3514235-4B06-11D1-AB04-00C04FC2DCD2. Otherwise, you cannot parse this traffic.
For more information, see 4.1.29 IDL_DRSAddCloneDC (Opnum 28).

There is a new group added when installing a Windows Server 2012 DC into the environment called “Cloneable Domain Controllers” which controls which DCs can be cloned. Only DCs that will soon be cloned should be in this group and removed after they are cloned. Note that new DCs created through cloning are added to this group by default.

Cloning a DC:

1. Identify the “source DC” and copy the DC’s files VM related files.
2. Add the source DC’s computer object to the “Cloneable Domain Controllers” global security group or the new cloned DC will be booted into Domain Services Restore Mode.
3. Run the Powershell command New-ADDCCloneConfig which performs the following checks:* PDC Emulator is Windows Server 2012 or later
   * Source domain controller is a member of Cloneable Domain Controllers group
   * Source domain controller does not include any excluded applications or services
   * Source domain controller does not already contain a DcCloneConfig.xml at the specified pathScript Example:
   New-ADDCCloneConfigFile `
   –CloneComputerName  MCLABDC03`
   -IPv4Address 10.10.10.13 `
   -IPv4DefaultGateway 10.10.10.1 `
   -IPv4SubnetMask 255.255.0.0  `
   -IPv4DNSResolver 10.10.10.11,10.10.10.12  `
   -Static `
   -SiteName HQSite `

   NOTE: Omitting the CloneComputerName parameter will force the Powershell script to create the name based on the source DC. For example, if the SourceDC is “MCLABWXYZDC02″, then the automatically created name is “MCLABWXY–CL0001″. The script takes the first 8 characters from the source DC name and adds “-CL####” up to “-CL9999″.

   After these checks are complete, the script creates the DC Clone Config file in one of the following locations:

   * DSA Working Directory
   * %windir%\NTDS
   * Removable read/write media, in order of drive letter, at the root of the drive

4. Shut down the source DC VM and export it. The source DC must be shut down gracefully.
5. Import the new VM and start it up.
6. When the new DC starts up, it checks for the DCCloneConfig.xml file and if it exists, the cloning process is initiated.

References:

• Virtual Domain Controller Cloning in Windows Server 2012
• Safely Cloning an Active Directory Domain Controller with Windows Server 2012 – Step-by-Step
• Virtualized Domain Controller Deployment and Configuration
• New-ADDCCloneConfigFile

Active Directory Domain Controllers running Windows Server 2012 can now identify if they are virtualized and have been improperly restored or cloned (copied). Windows Server 2012 introduces a new feature called the VM Generation ID which is used to track the virtual machine (VM) on which the OS is running. When a new VM is created in a hypervisor that supports the feature (Hyper-V 2012 & VMWare vSphere 5.1), a VM Generation ID is created by the hypervisor and associated with the VM as the unique VM guest identifier. The VM Generation ID is a 128-bit cryptographically random  integer that changes when the VM’s configuration file changes. The virtual machine’s BIOS provides the VM Generation ID to the OS in an 8-byte aligned buffer in guest RAM, ROM, or device memory space which can be queried via ACPI namspace with a compatible ID of “VM Gen Counter” (also a DOS Device Name of “VM_Gen_Counter”. When the generation ID changes, there is an ACPI Notify operation on the generation ID device ID device using notification code 0×80 (an ACPI GPE can triger this notification).

Each Domain Controller has a unique identifier called the Invocation ID for the Active Directory database instance on that DC. When a DC is backed up and restored, the Invocation ID changes. Each DC tracks changes it makes to its local AD database, NTDS.dit, using an incremental counter called the Update Sequence Number (USN). Active Directory replication leverages a combination of the InvocationID and the USN in order to determine what data a DC requests from other DCs. The USN normally only increases in value; however, there are circumstances where a “USN rollback” occurs such as when a DC’s VM snapshot is restored. With a USN roollback, the DC is improperly restored to a point in time “rolling back” the USN to a previous value. The DC doesn’t have AD data that other DCs have and believe that it has (for more information, read my article on the subject: USN rollback). The new VM Generation ID protects against this scenario.

At first boot-up, a virtualized Windows Server 2012 Domain Controller queries the hypervisor for the VM Generation ID and stores it in in the Active Directory database file (NTDS.dit). Each time the DC is rebooted, the VM’s current VM Generation ID is compared with the value in the DC’s NTDS.dit file (ms-DS-Generation-Id). If the values are different, the DC resets the invocation ID, discards the RID pool, and updates the value in the DC’s NTDS.dit file.  The DC also non-authoritatively synchronizes the SYSVOL folder to ensure proper operation and replication.

NOTE: The ms-DS-Generation-Id computer attribute does not replicate – to view a specific DC’s Generation ID, query for it on that DC.

Here’s the value when viewed in ADUC on the DC:

Powershell command to view the VM Generation ID associated with a 2012 DC:
Import-module activedirectory ;
(Get-ADObject “CN=MCLABDC01,OU=Domain Controllers,DC=MCLAB,DC=net” -server mclabdc01.mclab.net -property msds-generationid).’msds-generationid’

You may notice in the graphic above that when querying DC02 for DC01′s msds-generationid attribute value, it is blank. Since this value does not replicate, you have to query for the value on the DC that stores the value.

This feature also provides the capability to clone (copy) Domain Controllers.

Scenarios where the VM Generation ID is changed:

• Virtual machine starts executing a snapshot.
• Virtual machine is recovered from a backup.
• Virtual machine is failed over in a disaster recovery environment.
• Virtual machine is imported, copied, or cloned.
• Virtual machine’s configuration changes (depending on change).
• Virtual machine is moved from a hypervisor host not supporting VM Generation ID to one that does.

Only Domain Controllers running Windows Server 2012 on a Hyper-V 2012 or VMWare vSphere 5.1 VM support this feature.

VMWare VM-Generation-ID support:

• VMware vSphere 5.0 Update 2 (vCenter Server and ESXi must both be at 5.0 Update 2)
• VMware vSphere 5.1 (ESXi must be at least 5.0 Update 2)

Some key caveats:

With this new capability come several requirements and limitations:

* A restored domain controller must be able to contact a writable DC.

If restored, a domain controller must have connectivity to a writable domain controller; a read-only domain controller cannot send the delta of updates. The topology is likely correct for this already, as a writable domain controller always needed a writable partner. However, if all writable domain controllers are restoring simultaneously, none of them can find a valid source. The same goes if the writable domain controllers are offline for maintenance or otherwise unreachable through the network.

* All domain controllers in a domain must not be restored simultaneously.

If all snapshots restore at once, Active Directory replication works normally but SYSVOL replication halts. The restore architecture of FRS and DFSR require setting their replica instance to non-authoritative sync mode. If all domain controllers restore at once, and each domain controller marks itself non-authoritative for SYSVOL, they all will then try to synchronize group policies and scripts from an authoritative partner; at that point, though, all partners are also non-authoritative.

* Any changes originating from a restored domain controller that have not yet replicated outbound since the snapshot was taken are lost forever.

Here’s an excerpt from Microsoft Article: Introduction to Active Directory Domain Services (AD DS) Virtualization (Level 100):

Safe virtualization of domain controllers:

Virtual environments present unique challenges to distributed workloads that depend upon a logical clock-based replication scheme. AD DS replication, for example, uses a monotonically increasing value (known as a USN or Update Sequence Number) assigned to transactions on each domain controller. Each domain controller’s database instance is also given an identity, known as an InvocationID. The InvocationID of a domain controller and its USN together serve as a unique identifier associated with every write-transaction performed on each domain controller and must be unique within the forest.

AD DS replication uses InvocationID and USNs on each domain controller to determine what changes need to be replicated to other domain controllers. If a domain controller is rolled back in time outside of the domain controller’s awareness and a USN is reused for an entirely different transaction, replication will not converge because other domain controllers will believe they have already received the updates associated with the re-used USN under the context of that InvocationID.

For example, the following illustration shows the sequence of events that occurs in Windows Server 2008 R2 and earlier operating systems when USN rollback is detected on VDC2, the destination domain controller that is running on a virtual machine. In this illustration, the detection of USN rollback occurs on VDC2 when a replication partner detects that VDC2 has sent an up-to-dateness USN value that was seen previously by the replication partner, which indicates that VDC2’s database has rolled back in time improperly.

A virtual machine (VM) makes it easy for hypervisor administrators to roll back a domain controller’s USNs (its logical clock) by, for example, applying a snapshot outside of the domain controller’s awareness. For more information about USN and USN rollback, including another illustration to demonstrate undetected instances of USN rollback, see USN and USN Rollback.

Beginning with Windows Server 2012, AD DS virtual domain controllers hosted on hypervisor platforms that expose an identifier called VM-Generation ID can detect and employ necessary safety measures to protect the AD DS environment if the virtual machine is rolled back in time by the application of a VM snapshot. The VM-GenerationID design uses a hypervisor-vendor independent mechanism to expose this identifier in the address space of the guest virtual machine, so the safe virtualization experience is consistently available of any hypervisor that supports VM-GenerationID. This identifier can be sampled by services and applications running inside the virtual machine to detect if a virtual machine has been rolled back in time.

How do these virtualization safeguards work?

---

During domain controller installation, AD DS initially stores the VM GenerationID identifier as part of the msDS-GenerationID attribute on the domain controller’s computer object in its database (often referred to as the directory information tree, or DIT). The VM GenerationID is independently tracked by a Windows driver inside the virtual machine.

When an administrator restores the virtual machine from a previous snapshot, the current value of the VM GenerationID from the virtual machine driver is compared against a value in the DIT.

If the two values are different, the invocationID is reset and the RID pool discarded thereby preventing USN re-use. If the values are the same, the transaction is committed as normal.

AD DS also compares the current value of the VM GenerationID from the virtual machine against the value in the DIT each time the domain controller is rebooted and, if different, it resets the invocationID, discards the RID pool and updates the DIT with the new value. It also non-authoritatively synchronizes the SYSVOL folder in order to complete safe restoration. This enables the safeguards to extend to the application of snapshots on VMs that were shutdown. These safeguards introduced in Windows Server 2012 enable AD DS administrators to benefit from the unique advantages of deploying and managing domain controllers in a virtualized environment.

The following illustration shows how virtualization safeguards are applied when the same USN rollback is detected on a virtualized domain controller that runs Windows Server 2012 on a hypervisor that supports VM-GenerationID.

In this case, when the hypervisor detects a change to VM-GenerationID value, virtualization safeguards are triggered, including the reset of the InvocationID for the virtualized DC (from A to B in the preceding example) and updating the VM-GenerationID value saved on the VM to match the new value (G2) stored by the hypervisor. The safeguards ensure that replication converges for both domain controllers.

With Windows Server 2012, AD DS employs safeguards on virtual domain controllers hosted on VM-GenerationID aware hypervisors and ensures that the accidental application of snapshots or other such hypervisor-enabled mechanisms that could ‘rollback’ a virtual machine’s state does not disrupt the AD DS environment (by preventing replication problems such as a USN bubble or lingering objects). However, restoring a domain controller by applying a virtual machine snapshot is not recommended as an alternative mechanism to backing up a domain controller. It is recommended that you continue to use Windows Server Backup or other VSS-writer based backup solutions.

References:

• Microsoft Article: Introduction to Active Directory Domain Services (AD DS) Virtualization (Level 100)
• Microsoft Virtual Machine Generation ID Whitepaper document
• Virtualize your Windows Server 2012 domain controllers
• Things to consider when you host Active Directory domain controllers in virtual hosting environments
• Virtualized Domain Controller Deployment and Configuration
• Windows Server 2012 VM-Generation ID Support in vSphere
• ms-DS-Generation-Id Attribute

Here are some of the major updates:

• Virtualization: Rapid deployment with cloning & safeguarding
• Dynamic Access Control
• DirectAccess Offline Domain Join
• Active Directory Federation Services (AD FS)
• Active Directory Administrative Center Improvements
• PowerShell version 3 commandlets including Active Directory Replication and Topology (Introduction & Advanced Topics)
• Windows PowerShell History Viewer
• Active Directory Recycle Bin User Interface
• Fine-Grained Password Policy User Interface
• Active Directory Based Activation
• Group Managed Service Accounts
• Flexible Authentication Secure Tunneling (FAST) (RFC 6113) adds additional security to Kerberos (also known as Kerberos Armoring) and requires Windows Server 2012 with Windows 8.
• RID Improvements: Protection & Expansion
• Kerberos Constrained Delegation now possible across forests
• Enhanced LDAP logging and new controls
• Deferred Index Creation – DCs can be configured to build indexes at reboot or via LDAP control versus the default: immediate index creation.
• Ability to track DNT usage on Windows Server 2012 DCs using perfmon.

Microsoft article: “What’s New in Active Directory Domain Services (AD DS)”

Microsoft WhitePaper: Windows Server 2012 Evaluation Guide (pdf download)

Here’s a list:

• Modernizing Your Datacenter
• Windows Server 2012 Overview
• What’s New in Windows Server 2012 Hyper-V, Part 1
• Windows Server 2012 VDI/RDS Infrastructure and Management
• What’s New in Windows Server 2012 Hyper-V, Part 2
• Windows Server 2012 Networking Performance and Management
• Windows Server 2012 Dynamic Access Control Overview
• Compete to Win, Part 1- Comparing Core Virtualization Platforms
• Inside Windows Server 2012 Multi-Server Management Capabilities
• Cluster Shared Volumes Reborn in Windows Server 2012- Deep Dive
• The Path to Continuous Availability with Windows Server 2012
• Dell Windows Server 2012 Greenfield Data Design – Hosted Server / Private Cloud
• Windows Server 2012 Hyper-V Storage
• What’s New in Active Directory in Windows Server 2012
• RemoteFX and RDP Rocking RDS in Windows Server 2012
• Hyper-V over SMB2- Remote File Storage Support in Windows Server 2012 Hyper-V
• Standards Support and Interoperability in Windows Server 2012- Storage, Networking, and Management
• Deploying Windows Server 2012- From Bare Metal, Server Core, Minimal Server Interface, and More
• Windows Server 2012 NIC Teaming and Multichannel Solutions
• Windows Server 2012 Dynamic Access Control Deep Dive for Active Directory and Central Authorization
• Hyper-V High-Availability and Mobility- Designing the Infrastructure for Your Private Cloud
• Windows Server 2012 + Advanced Storage Solutions = Datacenter Elevation
• Building a Highly Available Failover Cluster Solution with Windows Server 2012 from the Ground Up
• Windows Server 2012 File and Storage Services Management
• An Overview of Hyper-V Networking in Windows Server 2012
• Windows Server 2012 Dynamic Access Control Best Practices and Case Study Deployments in Microsoft
• Active Directory Virtualization Safeguards and Domain Controller Cloning with Windows Server 2012
• Get Hands-on with the New Hyper-V Extensible Switch in Windows Server 2012
• Windows Server 2012 Storage Solutions- Vast Storage Capabilities for Everyone
• Update Management in Windows Server 2012- Revealing Cluster-Aware Updating and the New Generation of WSUS
• Windows Server 2012 IP Address Management
• Windows Server 2012 DirectAccess- How to Quickly and Easily Deploy Your Next Generation Remote Access Experience
• Windows Server 2012 High-Performance, Highly-Available Storage Using SMB
• Windows Server 2012 File System Enhancements- Redefining File Storage
• Hyper-V Network Virtualization for Scalable Multi-Tenancy in Windows
• Windows Server 2012- A Techie’s Insight into the Hot New Features
• Networking for Hybrid Cloud- BranchCache and Cross Premise Connectivity
• Windows Server 2012- Cluster-in-a-Box, RDMA, and More
• Using the Windows Server 2012 Server Manager for Remote and Multi-Server Management
• Building Flexible Hyper-V Environments Windows Server 2012 Hyper-V Live Migration and Live Stora
• Preparing for The Big One – Protection and Recovery Using New Capabilities of Windows Server 2012 & System Center 2012 SP1
• The Evolution of Active Directory Recovery
• What’s New with Windows Server 2012 and Microsoft System Center 2012 SP1
• Guest Clustering and VM Monitoring in Windows Server 2012
• Deploying Private Clouds (Lessons Learned from the Windows Server 2012 TAP)
• DNSSEC Deployment with Windows Server 2012
• Building Hosted Public and Private Clouds Using Windows Server 2012

From:  Kurtsh.com

Hi All! DougG here to share some insight on password policies – enjoy.

We were all excited when Windows 2008 Domain Functional level introduced FGPP (Fine Grained Password Policies). After several years in the field I have not seen abuse of this feature. In-fact, I am pleased to share that those using the FGPP are taking the conservative approach. By that, I mean I am not finding 20 or 30 FGPPs in domains. Rather, only 1 to 3 FGPP have been typically sufficient for most customers using FGPP. This means you are still using the Default Domain Policy to manage passwords for users that do not have a FGPP applied to them.

It is the Domain Password Policy that is the more complex of the two and the reason for this post.

WARNING!

First and for most, if you try to demo this or follow along on a domain make sure you are in a lab environment. What I am about to show you will impact the users and if you are in a production environment this will cause an RPE or CLM (Resume’ Producing Event or Career Limiting Move) – take your pick.

If you know these three facts you will be able to understand why things work the way they do.

1. Only policies applied at the DOMAIN level will apply a password policy to domain users. This can be the Default Domain Policy DDP or a policy that you have added that has a higher precedence (lower number than the DDP). Or it can be a combination of policies at the domain level.

2. Any policies applied to OUs, INCLUDING the domain controller OU, which has password policies will not be applied.

3. The password policy is written at the domain head by the PDCe (remember the stance that we don’t support sub OUs for domain controllers?)

Where do we get tripped up? RSOP for one. RSOP results will show you the policy including any OU that has a password policy setting. But only policies at the Domain level apply to the domain users. So when you look at an RSOP result you scratch your head, because what the user is experiencing is not what is on the RSOP report.

For example: If you wanted users in a specific OU to have shorter password length requirement and applied a password policy on their OU you will see your new settings in an RSOP report for those users.

Continue reading the article.

The script provides a count of discovered trusts and if there is 1 or more discovered, it displays the trust information.

Here’s the code:

References:

There’s a lot of useful information in these posts:

10.) Want Remote PowerShell Management from your browser? See how PowerShell Web Access in Windows Server 2012 may help…

9.) Slow Boot Slow Logon (SBSL), A Tool Called XPerf and Links You Need To Read

8.) MCM: Core Active Directory Internals

7.) How to Implement the Central Store for Group Policy Admin Templates, Completely (Hint: Remove Those .ADM files!)

6.) HYPER-V 2008 R2 SP1 Best Practices (In Easy Checklist Form)

5.) How to become a Premier Field Engineer (PFE)

4.) Virtual Domain Controller Cloning in Windows Server 2012

3.) Windows Server 2012 Storage Spaces: Is it for you? Could be…

2.) Introducing the first Windows Server 2012 Domain Controller (Part 1 of 2)

1.) Did Your Active Directory Domain Time Just Jump To The Year 2000? / Fixing When Your Domain Traveled Back In Time, the Great System Time Rollback to the Year 2000

Here’s the full blog post.

While studying the new 2012 cmdlets in preparation for conference talks last summer I created a quick cheat sheet for PowerShell equivalence to REPADMIN and DNSCMD. The other day I sat down and expanded this to include a raft of familiar utilities:

REPADMIN DCPROMO CSVDE NETDOM NLTEST GPUPDATE GPRESULT

DSGET DSQUERY DSADD DSMOD DSRM DSMOVE DSACLS

DNSCMD NSLOOKUP PING IPCONFIG NETSTAT

This guide will get you off and running to convert any old batch files you still have lying around or hiding in scheduled tasks.

Download the PDF from Goatee PFE

Install from media (IFM) contains two important things.

• NTDS.DIT (Active Directory Database) – at the time the IFM is generated (Regardless of Windows Server 2003, Windows Server 2008 or later –the NTDS.dit is pretty much unchanged until DCPROMO makes a lot of changes at the becoming domain controller that takes use of the database – it will change the DSA reference and update related “instance specific” information in the hidden table )
• SYSVOL (SYSVOL GPT Storage)
• Registry (Contains the SYSKEY used to decrypt the PEK (also known as Password Encryption Key) that efficiently ensure that the protection for sensitive information stored in the Active Directory database (Such as Password Hashes) are unique to each instance of the database (read each domain controller) –Note: This doesn’t apply to RODCs .

• Part 1
• Part 2

ASKPFE: MCM: Active Directory Indexing For the Masses

More detailed information on the AskPFE blog:

Hey y’all, Mark back again with some more detail around what to when the system time rollback to November 19^th 2000, caused Active Directory replication and other time-sensitive operations to fail in your environment. This post contains guidance by a small army of Microsoft PFEs, support professionals and developers. If you have any questions about the recommendations in this post, feel free to give CTS a call and they can guide you through the recovery. Recovering from a time rollback is a complex situation so read each step carefully and don’t skip ahead or you’ll make the problem worse. Also this post is going to be a long one and will probably break the record for additional links so you’ll want to get comfortable.

Here is what this post is going to cover.

How Did This Happen?

What Are The Symptoms?

Mitigation

1.) Correct Time

2.) Check For Replication Errors

3.) Additional Mitigation

Ongoing Tasks

How Did This Happen?

On November 19th, 2012, time servers at USNO.NAVY.MIL incorrectly provided time samples listing CY 2000 as the current year between the hours of 21:07 UTC and 21:59 UTC (16:07-16:59 EST). Get more info here.

Forests most impacted by this time rollback shared two traits:

1. The forest root PDC or master time servers in the forest lacked time jump protection discussed in in KB 884776 (probably because they were running the W2K3 OS)

2. The forest contained Windows Server 2003 DCs (more on this below)

Windows added support for time jump protection starting with the Server 2003 (and XP member workstations) in the form of two registry values: MaxPosPhaseCorrection and MaxNegPhaseCorrection (we’ll refer to both these keys going forward as max*phasecorrection). By default, the max*phasecorrection settings are not populated on Windows Server 2003 DCs. As a result, such DCs adjust the system time after receiving forward or back-dated time samples. Windows Sever 2008 and later DCs set the max*phasecorrection settings to 48 hours and ignore time samples that vary by more than 48 hours from locally configured time.

Time jump protection is not defined on Windows member workstations or servers until enabled by an administrator for the following reasons. Microsoft Commercial Support has observed massive time jumps (from days to multiple decades in the past and future) in customer forests for the last 10 years. Multiple root causes exist but up until now have never been caused by a highly accurate time servers giving out inaccurate time. While the max*phasecorrection settings offer a degree of protection when the time service is running, it offers no protection when inaccurate time is adopted during a reboot or while the time service is not running. Furthermore, the use of max*phasecorrection can prevent client and server computers from adjusting back to accurate time. While smaller max*phasecorrection values make Windows time clients less susceptible to adopting bad time, they also make it hard for such clients to self-correct if good time varies by more than max*phasecorrection seconds in the past or future. For example, setting max*phasecorrection to say 1 hour would prevent time client from self-correcting from a time zone or AM | PM misconfiguration. Given the ratio of domain controllers to member servers and workstations, Microsoft elected not to configure time jump protection on such computers. More information on time jump protection can be found in KB 884776.

Read the rest of the AskPFE Article here.

The ASKPFE blog has an excellent article covering this new feature:

Tom Moser here with a post on one of the new ADDS features in Windows Server 2012; Virtual Domain Controller Cloning.

Until now, cloning, snapshotting, copying, or pretty much doing anything but rebuilding from scratch to a virtual domain controller wasn’t just unsupported; it had the potential to be really bad for your directory. Cloning or restoring snapshots of DCs could result in USN rollbacks or lingering objects, just to name a couple of problems.

Starting in Windows Server 2012, we now support DC cloning as well as snapshot restoration of domain controllers. With the RTM bits available, I found myself rebuilding my lab and took the opportunity to document the process to demonstrate just how easy it is to clone virtual domain controllers with Windows Server 2012.

Requirements

There are a few base infrastructure requirements to take advantage of DC cloning.

• The hypervisor must support VM-GenerationID. Hyper-V running on Windows Server 2012 supports this feature. Other virtualization vendors will have the ability to implement this as well, so check with your vendor to see if it’s supported.
• The source virtual DC must be running Windows Server 2012.
• The PDC emulator role holder must be online and available to the cloned DC and must be running Windows Server 2012.

There are a few other steps and requirements and I’ll take you through those now.

Read the rest of the article here.

Anyway, what with the hiring we’re doing now, a month ago I promised you some further reading around how you can amp up your Active Directory skills. Rather than burying it in another mail sack, I figured I’d lay it all out here in one spot. If you feel like you need to fill in the cracks on your directory service knowledge, here’s what we force feed our new hires

Core Technology Reading

If you read nothing else, read these core pieces. While they are Win2003/XP specific, that’s still at least 75% of the business install base and highly relevant. For the most part things don’t change that much architecturally between versions either (ignoring GP and User Profiles). They give you the fundamentals to build on later.

Active Directory Collection
Active Directory Replication Model
Active Directory Replication Topology
Authentication
Authorization
DNS Technical Reference
Group Policy
Interactive Logon
Kerberos Authentication Technical Reference
Public Key Infrastructure (PKI)
TCP/IP Technical Reference
User Profiles

Post Graduate Technology Reading

Then we get to the more advanced subjects, the specific features added in later models, and the things that will take you into rarefied air. Much of this is Windows Server 2008 and later too, so if you haven’t started rolling out our later OS this will get you ready. If you can get through these, you’re ready to run AD in the environments with 100,000+ computers. And as I always tell people, if you know how something works, you can troubleshoot any kind of problem – even if the issue has never seen seen before.

Active Directory Domain Services in the Perimeter Network
Active Directory and Active Directory Domain Services Port Requirements
Active Directory Schema
ADMT Guide: Migrating and Restructuring Active Directory Domains
AppLocker
AD DS Design Guide
CA Certificates
Certificates
Certificate Services
Core Group Policy Technical Reference
Designing a Group Policy Infrastructure
DFSR
DFS Replication: Frequently Asked Questions (FAQ)
Distributed File System (DFS)
DNS Support for Active Directory
Domain and Forest Trusts Technical Reference
File Replication Service FRS
Global Catalog Technical Reference
Group Policy Components
Group Policy Management Console
Group Policy Object Editor
Logon and Authentication Technologies
Managed Service Accounts
Managing Roaming User Data Deployment Guide
Operations Masters Technical Reference
Read-Only Domain Controller Planning and Deployment Guide
Running Domain Controllers in Hyper-V
Security Auditing
Security Compliance Manager
Security Identifiers Technical Reference
Security Descriptors and Access Control Lists Technical Reference
Security Principals Technical Reference
Staging Group Policy Deployments
SYSVOL Replication Migration Guide: FRS to DFS Replication
User Account Control Technical Reference
What’s New in Active Directory Domain Services in Win2008
What’s New in Active Directory Domain Services in Win2008 R2
Windows Smart Card Technical Reference
Windows Time Service Technical Reference
WINS Technical Reference

Get the information here.

Greg Jaworski here again to discuss introducing the first Windows Server 2012 Domain Controller. We will discuss things such as extending the schema, enhancements to the Domain Controller promotion process (it is no longer called dcpromo), and things you should be doing to ensure a smooth upgrade and minimal issues. This will be a two part blog post. In the first part we will cover the GUI way of introducing the first Windows Server 2012 Domain Controller. In the second post we will cover the PowerShell way of doing this and also how you can take a look at your environment before introducing that first Windows Server 2012 Domain Controller.

Premier Field Engineering has significant experience in the area of AD upgrades. Many times we are onsite during various parts of the upgrade process. We also have discussions about upgrades during Active Directory Risk Assessments (ADRAP) and have an entire offering called the Active Directory Upgrade Assessment (ADUA) to assist with the upgrade process. We understand the concerns of upgrades. Many managers and IT people do not like the words irreversible, forest recovery, and no back-out plan. People also tend to not like mission critical applications breaking.

Read the rest of the article here.

Following up on Greg Jaworski’s great post from last week where he talked about how to promote a domain controller in Windows Server 2012, today we will cover some thoughts around where to place your first Windows Server 2012 DCs and how many to plan on rolling out at once.  This blog post is meant to be used as high level guidance as every environment is different, so your mileage most likely will vary.  If you are interested in a more detailed recommendation specific to your environment, I encourage you to speak with your Microsoft account team contact(s) to get you hooked up with the right resources at Microsoft to assist.

1. Where you place your first 2012 DCs and how many you need greatly depends on two things:
2. What new 2012 features you plan on using right out of the gate.If you have multiple domains and/or multiple forests with trusts in place.

Let’s break these down a bit more with some specific examples.  For those of you who have not looked into the new Windows Server 2012 features Dynamic Access Control (DAC), Kerberos FAST (AKA armoring), and DC cloning, some of this content may be a bit confusing.  We plan on covering these topics in greater detail in future blog posts.  In the interim, I encourage you to review the following links on TechNet for a quick review before and/or after reading the next section.

Read the rest of the article here.