Alexander’s Blog

Today I was installing Exchange Server 2010 Enterprise on a Windows Server 2008 R2 Domain Controller. Although Microsoft recommends that you install Exchange 2010 on a member server if possible, the environment I was working was very small so the Exchange Server 2010 was installed on a Domain Controller. There was an Exchange Server 2007 already in the same forest.

After I installed Exchange Server 2007 SP3 (at least SP2 was required in my scenario) to meet the prerequisites, I was unable to install Exchange Server 2010. During the installation I received the following error, indicating IIS was not installed on the Windows Server 2008 R2 server.

I installed IIS but still received the same error. The event viewer displayed the following warning:

Log Name:      System
Source:        Microsoft-Windows-WAS
Date:          7/10/2010 8:54:01 AM
Event ID:      5153
Task Category: None
Level:         Warning
Keywords:      Classic
User:          N/A
Computer: Exchange.SeattlePro.com

Description: The Windows Process Activation Service (WAS) encountered an error attempting to look up the built in IIS_IUSRS group.  There may be problems in viewing and setting security permissions with the IIS_IUSRS group.  This happens if the machine has been joined and promoted to be a Domain Controller in a legacy domain.  Please see the online help for more information and solutions to this problem.  The data field contains the error number.

Upon further investigation, I discovered that according to Microsoft KB article 946139, this is by design. Translation: This is a FEATURE, not a BUG.

Symptoms

You have a Windows Server 2008-based server that is running Internet Information Services (IIS) 7.0. You set the Windows Server 2008-based server as a domain controller of a Windows 2000-based domain or of a Windows Server 2003-based domain. In this scenario, you cannot resolve the built-in IIS accounts, such as the IIS_IUSRS group or the IUSR guest user account. You can see only the raw security identifier (SID) of the built-in IIS accounts.

Note: This problem does not occur if you set the Windows Server 2008-based server as a domain controller of a Windows Server 2008-based domain.

Reason

This problem occurs because the IIS 7.0 built-in accounts specification for Windows Server 2008 does not exist in earlier domains, such as Windows 2000-based domains and Windows Server 2003-based domains. When the IIS 7.0 server is set as a Windows 2000-based domain controller or a Windows Server 2003-based domain controller, the Windows Server 2008 accounts cannot be resolved.

Detailed Explanation

This TechNet article explains Event ID 5153 in more detail. Essentially, you have to remap the built-in IIS accounts. IIS 7.0 uses several built-in Windows Server 2008 accounts, including the IIS_IUSRS group and the IUSR guest user account. These replace the <MACHINE_NAME>_USR account that was created by IIS 6.0.

A problem occurs when a Windows Server 2008 computer that hosts IIS 7.0 becomes a domain controller (DC) of a non-Windows Server 2008 domain (that is, a DC of a Windows 2000 or Windows Server 2003 domain). When the DC promotion occurs, the new Windows Server 2008 built-in accounts are no longer available to IIS 7.0. Any Access Control List (ACL) that uses the built-in accounts will not be able to resolve to a friendly name, but will instead show their raw SID (Security Identifier) values.

To resolve this issue, run a script that will restore the mapping of SIDs to friendly names for the built-in accounts. The script must be run on the DC while it is connected to its Primary Domain Controller (PDC). This will reestablish access to the built-in accounts that IIS 7.0 requires.

Solution

To resolve this problem, use this sample script. Save it as SamUpgradeTask.js.

Note: You must restart the server after you run this script.

Troubleshooting Tips

After you have taken all these steps you may still get the same error, at least I did, and I know others have been in the same boat. Try these additional steps.

1. Go to Server Manager/Web Server (IIS)/Add role services and check the box for IIS 6 Management Compatibility. If that doesn’t help then go to step 2.

2. Start the PowerShell with elevated privileges (Start, All Programs, Accessories, Windows PowerShell) and run the following scripts one-by-one. You must start the PowerShell with elevated privileges, i.e. Run as Administrator.

Import-Module ServerManager

Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy -Restart

Set-Service NetTcpPortSharing -StartupType Automatic

---

Copyright ©2010 Zubair Alexander. All rights reserved.

When you add a Windows Server 2008 Server in your Windows Server 2003 domain, you have to update the schema. You may notice that when you use Active Directory Users and Computers on your Windows Server 2003 Domain Controller, you get the following error:

MMC has detected an error in a snap-in. It is recommended that you shut down and restart MMC.

According to Microsoft “This problem occurs because the Adsiedit.dll module uses an uninitialized pointer. When the system frees this pointer, some random data is freed. Therefore, an access violation may occur.”

You can download the hotfix from Microsoft to fix the problem. Check out the KB article 946549 for more details.

In Windows Server 2003 Active Directory domains, there is a concept of immediate and urgent replication. Certain types of information gets replicated immediately, rather than waiting for the standard Active Directory replication. One such example is user account lockout. If an administrator locks a user account, the information is replicated to the PDC emulator immediately. Microsoft recommends that you define account lockout and password policies in only one Group Policy object (GPO) for every domain (in the Default Domain policy settings).

Microsoft explains the concepts of immediate and urgent replications in this TechNet article:

Account lockout relies on the replication of lockout information between domain controllers to ensure that all domain controllers are notified of an accounts status. In addition, password changes must be communicated to all domain controllers to ensure that a user’s new password is not considered incorrect. This data replication is accomplished by the various replication features of Active Directory and is also discussed in this section.

Immediate Replication
When you change a password, it is sent over Netlogon’s secure channel to the PDC operations master. Specifically, the domain controller makes a remote procedure call (RPC) to the PDC operations master that includes the user name and new password information. The PDC operations master then locally stores this value.

Immediate replication between Windows 2000 domain controllers is caused by the following events:
- Lockout of an account
- Modification of a Local Security Authority (LSA) secret
- State changes of the Relative ID (RID) Manager

Urgent Replication
Active Directory replication occurs between domain controllers when directory data is updated on one domain controller and that update is replicated to all other domain controllers. When a change in directory data occurs, the source domain controller sends out a notice that its directory store now contains updated data. The domain controller’s replication partners then send a request to the source domain controller to receive those updates. Typically, the source domain controller sends out a change notification after a delay. This delay is governed by a notification delay. (The Windows 2000 default notification delay is 5 minutes; the Windows Server 2003 default notification delay is 15 minutes.) However, any delay in replication can result in a security risk for certain types of changes. Urgent replication ensures that critical directory changes are immediately replicated, including account lockouts, changes in the account lockout policy, changes in the domain password policy, and changes to the password on a domain controller account. With urgent replication, an update notification is sent out immediately, regardless of the notification delay. This design allows other domain controllers to immediately request and receive the critical updates. Note, however, that the only difference between urgent replication and typical replication is the lack of a delay before the transmission of the change notification. If this does not occur, urgent replication is identical to standard replication. When replication partners request and subsequently receive the urgent changes, they receive, in addition, all pending directory updates from the source domain controller, and not only the urgent updates.

When either an administrator or a delegated user unlocks an account, manually sets password expiration on a user account by clicking User Must Change Password At Next Logon, or resets the password on an account, the modified attributes are immediately replicated to the PDC emulator operations master, and then they are urgently replicated to other domain controllers that are in the same site as the PDC emulator. By default, urgent replication does not occur across site boundaries. Because of this, administrators should make manual password changes and account resets on a domain controller that is in that user’s site.

The following events are not urgent replications in Windows 2000 domains:
- Changing the account lockout policy
- Changing the domain password policy
- Changing the password on a computer account
- Domain trust passwords

NetDom is a command-line tool that is built into Windows Server 2008. It is available if you have the Active Directory Domain Services (AD DS) server role installed. To use NetDom, you must run the NetDom command from an elevated command prompt. To open an elevated command prompt, click Start, right-click Command Prompt, and then click Run as administrator.

You can use NetDom to:

- Join a computer that runs Windows XP Professional or Windows Vista to a Windows Server 2008 or Windows Server 2003 or Windows 2000 or Windows NT 4.0 domain.

- Provide an option to specify the organizational unit (OU) for the computer account.

- Generate a random computer password for an initial Join operation.

- Manage computer accounts for domain member workstations and member servers. Management operations include:

- Add, Remove, Query.

- An option to specify the OU for the computer account.

- An option to move an existing computer account for a member workstation from one domain to another while maintaining the security descriptor on the computer account.

- Establish one-way or two-way trust relationships between domains, including the following kinds of trust relationships:

- From a Windows 2000 or Windows Server 2003 or Windows Server 2008 domain to a Windows NT 4.0 domain.

- From a Windows 2000 or Windows Server 2003 or Windows Server 2008 domain to a Windows 2000 or Windows Server 2003 or Windows Server 2008 domain in another enterprise.

- Between two Windows 2000 or Windows Server 2003 or Windows Server 2008 domains in an enterprise (a shortcut trust).

- The Windows Server 2008 or Windows Server 2003 or Windows 2000 Server half of an interoperable Kerberos protocol realm.

- Verify or reset the secure channel for the following configurations:

- Member workstations and servers.

- Backup domain controllers (BDCs) in a Windows NT 4.0 domain.

- Specific Windows Server 2008 or Windows Server 2003 or Windows 2000 replicas.

- Manage trust relationships between domains, including the following operations:

- Enumerate trust relationships (direct and indirect).

- View and change some attributes on a trust.

NetDom Commands

Here are the NetDom commands.

Command	Description
Netdom add	Adds a workstation or server account to the domain.
Netdom computername	Manages the primary and alternate names for a computer. This command can safely rename Active Directory domain controllers as well as member servers.
Netdom join	Joins a workstation or member server to a domain. The act of joining a computer to a domain creates an account for the computer on the domain, if it does not already exist.
Netdom move	Moves a workstation or member server to a new domain. The act of moving a computer to a new domain creates an account for the computer on the domain, if it does not already exist.
Netdom query	Queries the domain for information such as membership and trust.
Netdom remove	Removes a workstation or server from the domain.
Netdom movent4bdc	Renames a Windows NT 4.0 backup domain controller to reflect a domain name change. This can assist in Windows NT 4.0 domain renaming efforts.
Netdom renamecomputer	Renames a domain computer and its corresponding domain account. Use this command to rename domain workstations and member servers only. To rename domain controllers, use the netdom computername command.
Netdom reset	Resets the secure connection between a workstation and a domain controller.
Netdom resetpwd	Resets the computer account password for a domain controller.
Netdom trust	Establishes, verifies, or resets a trust relationship between domains.
Netdom verify	Verifies the secure connection between a workstation and a domain controller.

Microsoft has listed lots of examples on TechNet here. Here are some of them.

NetDom Examples

NOTE: The following examples apply to at least Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1 and Windows Server 2003 with SP2.

Example 1: Add a Workstation or Member Server to a Windows NT 4.0 Domain

To add the workstation mywksta to the Windows NT 4.0 domainreskita, type the following at the command line:

netdom add /d:reskita mywksta /ud:mydomain\admin /pd:password

Example 2: Add a Workstation or Member Server to a Windows Server 2003 Domain

To add the workstation mywksta to the Windows Server 2003 domain devgroup.example.com in the organizational unit (OU) Dsys/workstations, type the following at the command prompt:

netdom add/d:devgroup.example.com mywksta /OU:OU=Dsys,OU=Workstations,DC=microsoft,DC=com

Note

• If the /ou parameter is not specified, the account is created in the Computers container.

Example 3: Move a Windows NT 4.0 BDC to a new domain

To join myBDC to the Windows NT 4.0 domain reskita type the following at the command prompt:

netdom mybdc moveNT4BDC /domain:reskita

Example 4: Add an alternate name for a Windows Server 2003 domain controller

To give an alternate name for the domain controller DC in the example.com domain, use the following syntax:

netdom computername dc /add:altDC.example.com

A name must first exist as an alternate before it can be made the primary name of a computer.

Example 5: Rename a domain controller in a Windows Server 2003 domain

To rename the domain controller DC to altDC in the example.com domain use the following syntax:

netdom computername dc /makeprimary:altdc.example.com

To rename a member server you must choose one of the existing alternate names for the computer and make it the new primary name.

Example 6: Rename a Member Server

To rename the member server member to member1, type the following at the command prompt:

netdom renamecomputer member /newname:member1.example.com /userd:administrator

Example 7: Join a Workstation or Member Server to a Domain

To join mywksta to the devgroup.example.com domain in the Dsys/workstations organizational unit, type the following at the command prompt:

netdom join /d:devgroup.example.com mywksta /OU:OU=Dsys,OU=Workstations,DC=microsoft,DC=com

Besides adding the computer account to the domain, the workstation is modified to contain the appropriate shared secret to complete the join operation.

Example 8: Remove a Workstation or Member Server from a Domain

To remove mywksta from the mydomain domain and make the workstation a part of a workgroup, type the following at the command prompt:

netdom remove /d:mydomain mywksta /ud:mydomain\admin /pd:password

Example 9: Move a Workstation or Member Server from One Domain to Another

To move mywksta from its current domain into the mydomain domain, type the following at the command prompt:

netdom move /d:mydomain mywksta /ud:mydomain\admin /pd:password

If the destination is a Windows 2000 domain, the Security ID history (SIDHistory) for the workstation is updated, retaining the security permissions that the computer account had previously.

Example 10: Reset the secure channel for a workstation, member server, or Windows NT 4.0 BDC

To reset the secure channel secret maintained between mywksta and devgroup.example.com (regardless of OU), type the following at the command prompt:

netdom reset /d:devgroup.example.com mywksta

To reset the secure channel between the Windows NT 4.0 PDC for Northamerica and the backup domain controller NABDC, type the following at the command prompt:

netdom reset /d:Northamerica NABDC

Example 11: Force a Secure Channel Session Between a Member and a Specific Domain Controller

Members often establish secure channel sessions with non-local domain controllers. To force a secure channel session between a member and a specific domain controller by using the /server parameter with the reset operation, type the following at the command prompt:

netdom reset /d:devgroup.example.com mywksta /Server:mylocalbdc

Example 12: Verify a Workstation or Member Server Secure Channel

To verify the secure channel secret is maintained between mywksta and devgroup.example.com, type the following at the command prompt:

netdom verify /d:devgroup.example.com mywksta

Example 13: Establish a One-Way Trust Relationship

When used with the trust operation, the /d:Domain parameter always refers to the trusted domain.

To set the Windows NT 4.0 resource domain USA-Chicago to trust the Windows NT 4.0 account domain Northamerica, type the following at the command prompt:

netdom trust /d:Northamerica USA-Chicago /add /Ud:Northamerica\admin /Pd:* /Uo:USA-Chicago\admin /Po:*

Press Enter and the following prompt is displayed:

Password for Northamerica\admin:

Enter the password for Northamerica\admin and press Enter. The following prompt is displayed:

Password for USA-Chicago\admin:

Enter the password for USA-Chicago\admin and press Enter.

The user must have credentials for both domains. The /pd parameter can be used to specify the password for Northamerica\admin and the /po parameter can be used to specify the password for USA-Chicago\admin. If passwords are not provided on the command line, the user is prompted for both.

If you then want to specify a two-way trust, type the following at the command prompt

netdom trust /d:marketing.example.com engineering.example.com /add /twoway /Uo:admin@engineering.example.com /Ud:admin@marketing.example.com:

Example 14: Establish a One-Way Trust Relationship from a Windows Domain to a Non-Windows Kerberos Realm

To establish a one-way trust where Northamerica trusts the non-Windows Kerberos realm ATHENA, type the following at the command prompt:

netdom trust /d:ATHENA Northamerica /add /PT:password /realm

The /d parameter specifies the trusted domain and the /realm parameter indicates that this is a non-Windows Kerberos realm. The order of the domains is not important. Credentials to the Windows 2000 domain can be supplied if needed.

Note

• Verifying a specific trust relationship requires credentials unless the user has domain administrator privileges on both domains.

If you want to set the Kerberos realm ATHENA to trust the Northamerica domain, type the following at the command prompt:

netdom trust /d:Northamerica ATHENA /add

Note

• To make the trust two-way, you can specify the /twoway parameter.

Non-Windows Kerberos trusts are created as non-transitive. If you want to change the trust from ATHENA to Northamerica as transitive, type the following at the command prompt:

netdom trust Northamerica /d:ATHENA /trans:yes

To display the transitive state, type the following at the command prompt:

netdom trust Northamerica /d:ATHENA /trans

The order of the two domains above is not important. Either can be the non-Windows Kerberos domain.

Example 15: Break a One-Way Trust Relationship

To undo the trust that USA-Chicago has for Northamerica, type the following at the command prompt:

netdom trust /d:Northamerica USA-Chicago /remove

Example 16: Break a Two-Way Trust Relationship

To break a two-way trust relationship, type the following at the command prompt:

netdom trust /d:marketing.example.com Engineering.example.com /remove /twoway /Uo:admin@engineering.example.com /Ud:admin@marketing.example.com

Example 17: Verify a Specific Trust Relationship

To verify the one-way trust that USA-Chicago has for Northamerica, type the following at the command prompt:

netdom trust /d:Northamerica USA-Chicago /verify

To verify a two-way trust between the Northamerica and Europe domains, type the following at the command prompt:

netdom trust /d:Northamerica EUROPE /verify /twoway

The /verify parameter checks that the appropriate shared secrets are synchronized between the two items involved in the trust.

Example 18: Reset a Specific Trust Relationship

To reset the secure channel for the one-way trust between Northamerica and USA-Chicago, type the following at the command prompt:

netdom trust /d:Northamerica USA-Chicago /Ud:Northamerica\admin /reset

The /reset parameter synchronizes the appropriate shared secrets if they are not already synchronized.

Example 19: Verify Kerberos Functionality

To verify Kerberos authentication between a workstation and a service located in the domain devgroup.example.com, type the following at the command prompt:

netdom trust /d:devgroup.example.com /verify /KERBEROS

When you use the NetDom trust operation with the /verify /kerberos parameters, it seeks a session ticket for the Kerberos Admin service in the target domain. If successful, you can conclude that all Kerberos operations (for example KDC referrals) are operating correctly between the workstation and the target domain.

Note

• This operation cannot be executed remotely. It must be run on the workstation being tested.

Example 20: View All Workstation Members in a Domain

To list all the workstations in the domain Northamerica, type the following at the command prompt:

netdom query /d:Northamerica WORKSTATION

Example 21: View All Server Members in a Domain

To list all of the servers in Northamerica, type the following at the command prompt:

netdom query /d:Northamerica SERVER

Example 22: View All Domain Controller Members in a Domain

To list all the domain controllers in the domain Northamerica, type the following at the command prompt:

netdom query /d:Northamerica DC

Example 23: View All Organizational Unit Members in a Domain

To list all of the OUs in devgroup.example.com, type the following at the command prompt:

netdom query /d:devgroup.example.com OU

Example 24: List the Primary Domain Controller Member in a Domain

To list the PDC for Northamerica, type the following at the command prompt:

netdom query /d:Northamerica PDC

Example 25: List the Primary Domain Controller Emulator in a Domain

To list the current PDC emulator for devgroup.example.com, type the following at the command prompt:

netdom query /d:devgroup.example.com FSMO

NOTE: There are more examples on TechNet here.

Microsoft offers several spreadsheets that contain all the settings for group policies. These spreadsheets list the policy settings for computer and user configurations included in the Administrative template files delivered with the Windows operating systems specified. You can configure these policy settings when you edit Group Policy objects (GPOs).

Using column filters, you can filter the information in these spreadsheets by operating system, component, or computer or user configuration. You can also search for information by using text or keywords.

These spreadsheets include the following categories of security policy settings: Account Policies (Password Policy, Account Lockout Policy, and Kerberos Policy), Local Policies (Audit Policy, User Rights Assignment, and Security Options), Event Log, Restricted Groups, System Services, Registry, and File System policy settings. These spreadsheets do not include security settings that exist outside of the Security Settings extension (scecli.dll), such as Wireless Network extension, Public Key Policies, or Software Restriction Policies.

• Group Policy Settings Reference for Windows Server 2008 R2 and Windows 7: This spreadsheet lists the policy settings for computer and user configurations included in the Administrative template files (.admx/.adml) delivered with Windows Server 2008 R2 and Windows 7. The policy settings included in this spreadsheet cover Windows 7, Windows Server 2008 R2, Windows Server 2008, Windows Vista with SP1, Windows Server 2003 with SP2 and earlier service packs, Windows XP Professional with SP2 and earlier service packs, and Windows 2000 with SP4 and earlier service packs.
• Group Policy Settings Reference for Windows Server 2008 and Windows Vista Service Pack 1: This spreadsheet lists the policy settings for computer and user configurations included in the Administrative template files (.admx/.adml) delivered with Windows Server 2008 and Windows Vista with Service Pack 1 (SP1). The policy settings included in this spreadsheet cover Windows Server 2008, Windows Vista with SP1, Windows Server 2003, Windows XP Professional with SP2 or earlier service packs, and Windows 2000 with SP4 or earlier service packs.
• Group Policy Settings Reference for Windows Vista: This spreadsheet lists the policy settings for computer and user configurations included in the Administrative template files (.admx/.adml) delivered with Windows Vista with no service packs installed. The policy settings included in this spreadsheet cover Windows Vista, Microsoft Windows Server 2003, Windows XP Professional with SP2 or earlier service packs, and Windows 2000 with SP4 or earlier service packs.
• Group Policy Settings Reference for Windows Server 2003 Service Pack 2: This spreadsheet lists the policy settings for computer and user configurations included in the Administrative template (.adm) files and Security Settings that shipped with Windows Server 2003 with SP2. The policy settings included in this spreadsheet cover Microsoft Windows Server 2003 with SP2 or earlier service packs, Windows XP Professional with SP3 or earlier service packs, and Microsoft Windows 2000 with SP4 or earlier service packs.This spreadsheet includes separate worksheets for each of the .adm files and the security policy settings that shipped in Windows XP SP3, a consolidated worksheet for easy searching, and an Update History worksheet that lists policy settings that have been added since the Windows Server 2003 operating systems were released.