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.

Microsoft has published a 30-page white paper that provides information and guidelines for building scripts that can automate the installation of Office SharePoint Server 2007, the configuration of servers, and the creation and joining of farms. Code samples that you can copy and customize to match your farm and configuration are included.

The script will help you setup and configure the prerequisites, install the SharePoint Server, configure the services, and create and configure the sites.

WARNING! This white paper was last updated in 2008. I should warn you that the script that creates service accounts does not include the proper domain and groups right that are necessary. Read my blog about the service accounts that are necessary to properly install MOSS 2007 and then modify your script accordingly.

Download the white paper here.

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.

Windows Server 2008 (WS08) Server Core can be used in lots of useful scenarios. However, because WS08 does not have a GUI, you need to use the command prompt to accomplish the administrative tasks. You may find it convenient to manage the Server Core from another computer.

By default Remote Desktop is not enabled on the Server Core. There are two steps you need to take to get Remote Desktop working: Enable Remote Desktop & open default RDP port, which is TCP port 3889.

STEP 1 – Enable Remote Desktop

You can look at your settings by using the following command:

cscript c:\windows\system32\scregedit.wsf /AR /v

The scregedit.wsf script will either return a 1 or a 0. If you see a 1 then the Terminal Services (i.e. Remote Desktop) is disabled, a 0 means it is enabled.

To enable Terminal Services use the following command:

c:\windows\system32\scregedit.wsf /AR 0

To disable Terminal Services use the following command:

c:\windows\system32\scregedit.wsf /AR 1

NOTE: The /AR switch is used for Vista and WS08 computers. For Windows XP computers replace /AR with /CS.

STEP 2 – Open RDP Port

To open Remote Desktop, you need to make sure that your firewall is not blocking the default Terminal Services/RDP port 3389. On a WS08 Server Core, run the following command to open TCP port 3389.

netsh advfirewall firewall set rule group=”remote desktop” new enable=Yes

You should expect the following response when you execute the above command.

C:\Windows\system32>netsh advfirewall firewall set rule group=”remote desktop” new enable=Yes

Updated 2 rule(s).
Ok.

You might want to check out Microsoft KB article 947709 for additional information on opening ports at the firewall or how to enable ICMP requests.

---

Copyright ©2009 Zubair Alexander. All rights reserved.

The STSADM tool allows you to import and export SharePoint sites by specifying STSADM -0 Import and STSADM -o Export. The Import/Export options are ideal for backing up and restoring subwebs. To backup and restore entire site collections use STSADM -o Backup and STSADM -o Restore options.

Let’s say you want to backup a Demo subsite at http://www.seattlepro.com/demos and restore it to a different site at http://www.techgalaxy.net/demos. You can use the following method to export the demo site and then restore it to the intended destination. If you want to preserve permissions use the -includeusersecurity switch.

First, make sure STSADM is on your path so you can run it from any directory you want. Otherwise, run it from its default location at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN.

EXPORT SUBSITE

To export the subsite use the following syntax at the Command Prompt. Open the Command Prompt on the SharePoint server as an administrator if necessary.

C:\>stsadm -o export -url http://www.seattlepro.com/demos -filename DemoSiteBackup -includeusersecurity

You will see a single file called DemoSiteBackp.cmp that includes the exported content. You will also see a log file called DemoSiteBackup.export.log.

TIP: Just to make things easier, you might want to create a folder, like C:\SPBackups. Run the STSADM from that folder so the export file (DemoSiteBackup.cmp in our example) and the log file will be created in the same folder.

IMPORT SUBSITE

Now to import the subsite to a different site use the following syntax at the Command Prompt. Open the Command Prompt on the SharePoint server as an administrator if necessary.

C:\>stsadm -o import -url http://www.techgalaxy.net/demos -filename DemoSiteBackup.cmp -includeusersecurity

Notice that this time you need to provide the filename extension, which is .cmp. You should see the Demo site show up as a subsite in the destination site after the script has been successfully executed. You will also see a log file called DemoSiteBackup.cmp.import.log.

If you need to explore other import or export options, type stsadm -help import or stsadm -help export to see the complete syntax. For example:

 C:\>stsadm -help import

stsadm.exe -o import

           -url <URL to import to>

           -filename <import file name>

           [-includeusersecurity]

           [-haltonwarning]

           [-haltonfatalerror]

           [-nologfile]

           [-updateversions <1-3>

               1 - Add new versions to the current file (default)

               2 - Overwrite the file and all its versions (delete then insert)

               3 - Ignore the file if it exists on the destination]

           [-nofilecompression]

           [-quiet]

 

---

Copyright ©2009 Zubair Alexander. All rights reserved.