Brian Desmond

Transfer Domain FSMO Roles

You can transfer the three domain-wide FSMO roles (PDC Emulator, RID Master, and Infrastructure Master) with the GUI or via the command line. To transfer the roles via the GUI, follow the steps below. If the server curently hosting the role you want to transfer is unavailable, you must instead seize the roles.

Prior to attempting to transfer any of these roles, you must be a Domain Admin in the domain you will be performing the transfer. Once you have the appropriate access, perform the steps below for any of the roles you wish to transfer. In this example, we will transfer the PDC Emulator from a domain controller called COHO-CHI-ADC02.cohovines.com to a domain controller called COHO-CHI-SFO01.cohovines.com.

Launch the Active Directory Users and Computers (ADUC) MMC snap-in (Start>Run>dsa.msc).
Right click the Active Directory Users and Computers node and click Change Domain Controller.

Select the target domain controller (COHO-SFO-ADC01.cohovines.com in this example).
Right click the domain and click Operations Masters….

On the PDC tab, confirm the target domain controller is correct and then click Change….

Click Yes on the ensuing confirmation dialog.
If the operation succeeds, you will receive the message below:

You can repeat these steps for each of the other FSMO roles as necessary. If you want to transfer all of the roles to the same domain controller, you only need to repeat steps 5 – 7. Otherwise, you must repeat steps 2 – 7.

Transfer Forest FSMO Roles

You can transfer the two forest-wide FSMO roles (Schema Master and Domain Naming Master) with the GUI or via the command line. To transfer the roles via the GUI, follow the steps below. If the server curently hosting the role you want to transfer is unavailable, you must instead seize the roles.

Schema Master
Domain Naming Master

Transferring the Schema Master with the GUI

In this example, we will transfer the Schema Master FSMO role from a domain controller called COHO-CHI-ADC02.cohovines.com to a domain controller called COHO-SFO-ADC01.cohovines.com. You must first verify two prerequisites:

Ensure that you are using an account that is a member of the Schema Admins group.
Ensure you have registered the Active Directory Schema MMC snap-in by following these directions.

Once you have verified the prequisites, follow the steps below to transfer the Schema Master.

Open a new MMC (Start>Run>mmc) and add the Active Directory Schema snap-in.
Right click the Active Directory Schema node under Console Root and click Change Active Directory Domain Controller… as shown below:

Select the domain controller you want to transfer the Schema Master role to. In this example, I selected COHO-SFO-ADC01:

You will receive a warning that the Active Directory Schema snap-in is not connected to the Schema operations master. This is normal and can be ignored.

Right click the Active Directory Schema node under Console Root and click Operations Master….
The Change Schema Master dialog will show the current role holder (COHO-CHI-ADC02.cohovines.com in our example) and the target domain controller (COHO-SFO-ADC01.cohovines.com in our example). Confirm that the target server is the right server and then click Change.

Click yes on the ensuing confirmation dialog.
If the operation succeeds, you will receive the message below:

Transferring the Domain Naming Master with the GUI

In this example, we will transfer the Domain Naming Master FSMO role from a domain controller called COHO-CHI-ADC02.cohovines.com to a domain controller called COHO-SFO-ADC01.cohovines.com. Prior to beginning this procedure, you must be using an account that is a member of the Enterprise Admins group. Once you have verified that you have sufficient access, follow the steps below:

Launch the Active Directory Domains and Trusts MMC snap-in (Start>Run>domain.msc).
Right click Active Directory Domains and Trusts and click Change Active Directory Domain Controller….
Select the domain controller you want to transfer the Domain Naming Master role to. In this example, I selected COHO-SFO-ADC01:

Right click Active Directory Domains and Trusts and click Operations Master….
The Operations Master dialog will show the current role holder (COHO-CHI-ADC02.cohovines.com in our example) and the target domain controller (COHO-SFO-ADC01.cohovines.com in our example). Confirm that the target server is the right server and then click Change.

Click yes on the ensuing confirmation dialog.
If the operation succeeds, you will receive the message below:

How to Register Active Directory Schema MMC Snap-In

By default, the Active Directory Schema MMC snap-in is not registered on domain controllers or machines with the Remote Server Administration Tools (RSAT) installed. To use the snap-in for the first time on a new machine, you’ll need to register the DLL. To do this, follow the steps below:

Open an elevated command prompt
Run the following command: regsvr32 schmmgmt.dll
You should receive a success message:

Once you have registered the snap-in, you can add it to an MMC by following these steps:

Open a new MMC Console (Start>Run>mmc)
In the MMC Console, go to File>Add/Remove Snap-in
Add the Active Directory Schema snap-in as shown below:

Once you click OK, you’ll be able to access the snap-in through the MMC Console.

Remove an Offline Domain Controller

Sometimes domain controllers encounter catastrophic failures that take them off the network permanently – perhaps a hardware failure or an extended network outage that exceeds the tombstone lifetime. In these cases, the traditional process of demoting the domain controller won’t work and you’ll be forced to manually clean up Active Directory instead. This manual process is known as metadata cleanup. Metadata cleanup removes all of the references to the domain controller from Active Directory so that things like replication continue to work without error. Depending on what version of Windows you’re working with, this can be as simple as deleting the domain controller’s computer account with AD Users and Computers, or it might require a trip to the command line to put ntdsutil to work.

Windows Server 2008 and Newer (Active Directory Users and Computers)

The Windows Server 2008 version of Active Directory Users and Computers (ADUC) introduced a convenient one click approach to performing metadata cleanup. To take advantage of this feature, follow these steps:

If you are using the Windows Server 2003 version of ADUC, skip down to the NTDSUtil version of these steps. The Windows Server 2003 version of ADUC will not perform a metadata cleanup for you!

Launch ADUC (Start>Run>dsa.msc) and browse to the Domain Controllers OU.
Select the domain controller you want to delete. You will first receive the traditional prompt shown below:

Once you click Yes, you will subsequently receive a confirmation prompt similar to the one shown below:

If you’re certain that you want to proceed, check the box and click Delete. ADUC may prompt you for further confirmation if the domain controller is a Global Catalog or a FSMO role holder.

That’s all there is to it. If the domain controller ever comes back online, you must either erase the server and reinstall Windows or perform a forced demotion of the domain controller.

Windows Server 2003 (NTDSUtil)

If you’re running Windows Server 2003 or you would rather do a metadata cleanup using the command line, the NTDSUtil command line utility is what you’ll need.

Open an elevated command prompt
Type ntdsutil and press Enter.
Type metadata cleanup and press Enter.
Type connections and press Enter.
Type connect to server coho-chi-adc02 and press Enter.
Type quit and press Enter. After this step, your screen should look similar to the image below:

Type select operation target and press Enter.
Type list domains and press Enter.
Type select domain 0, where 0 is the number of the listed domain that contains the domain controller you want to clean up.
Type list sites and press Enter.
Type select site 0, where 0 is the number of the listed site that contains the domain controller you want to clean up. After this step, your screen should look similar to the image below:

Type list servers in site and press Enter.
Type select server 0, where 0 is the number of the listed server that you want to clean up. After this step, your screen should look similar to the image below:

If you discover that you selected the wrong domain or site, you can return to steps eight or ten.

Type quit and press Enter.
Type remove selected server and press Enter. You will be prompted to confirm your selection before continuing:

Once the process completes, you will see output similar to the following

Transferring / Seizing FSMO roles off the selected server.
Removing FRS metadata for the selected server.
Searching for FRS members under "CN=COHO-CHI-ADC01,OU=Domain Controllers,DC=cohovines,DC=com".

Removing FRS member "CN=COHO-CHI-ADC01,CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System,DC=cohovines,DC=com".
Deleting subtree under "CN=COHO-CHI-ADC01,CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System,DC=cohovines,DC=com".
Deleting subtree under "CN=COHO-CHI-ADC01,OU=Domain Controllers,DC=cohovines,DC=com".
The attempt to remove the FRS settings on CN=COHO-CHI-ADC01,CN=Servers,CN=Chicago,CN=Sites,CN=Configuration,DC=cohovines,DC=com failed because "Element not found.";
metadata cleanup is continuing.
"CN=COHO-CHI-ADC01,CN=Servers,CN=Chicago,CN=Sites,CN=Configuration,DC=cohovines,DC=com" removed from server "coho-chi-adc02"

This completes the process to manually remove a domain controller from Active Directory by performing a metadata cleanup with NTDSUtil.

How to Configure Time Synchronization on the PDC Emulator

Active Directory provides a time synchronization hierarchy that ensures that time dependent protocols such as Kerberos will work correctly. The PDC emulator in the forest root domain must be configured to synchronize with an authoritative external source – either a hardware clock, government time source, or another NTP server. As a matter of best practice, consider configuring a domain controller that has been identified as an alternate PDC emulator role holder to also synchronize with an external source. This way, if you transfer the PDCe FSMO role, you won’t need to reconfigure the time service on the new domain controller. Figure 2-5 from my book, Active Directory, 5th Edition shows how the time synchronization hierarchy works in a multi-domain forest:

To configure the forest root PDCe role holder to synchronize with the NTP Pool Project’s NTP servers, execute the following commands from an elevated command prompt:

w32tm /config /update /manualpeerlist:"0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.org" /syncfromflags:manual /reliable:YES
w32tm /resync /rediscover /nowait

How to Promote a Domain Controller

The process to convert a member server to a domain controller (DC) – known as promotion – requires a number of inputs to complete the wizard. As Active Directory has evolved, additional steps/inputs have been added to the wizard, but, the process itself has undergone very little change. If you are coming to Windows Server 2012 or newer from a previous version of Active Directory, the most noticeable change is that the dcpromo tool dating to Windows 2000 is gone. In fact, if you try to run dcpromo on a Windows Server 2012 or newer server, you’ll receive a message similar to this:

---------------------------
Active Directory Domain Services Installer
---------------------------
The Active Directory Domain Services Installation Wizard is relocated in Server Manager. For more information, see http://go.microsoft.com/fwlink/?LinkId=220921
---------------------------
OK
---------------------------

Instead of dcpromo, you’ll instead need to use the new Active Directory Domain Services Configuration Wizard that is accessible from Server Manager. Alternately, you can use Windows PowerShell to promote a domain controller as described here. To begin, you’ll need to install the Active Directory Domain Services (AD DS) server role.

Open Server Manager and click Add roles and features.
During the Installation Type step, choose Role-based or feature-based installation.
In the Server Selection step, ensure the local server is selected.
Select the Active Directory Domain Services role as shown below.

In the Features step, accept the defaults. Windows will automatically add additional features that are necessary to support AD DS.
Continue through the wizard to the Results step. Once the AD DS role installation completes, click the Promote this server to a domain controller link as highlighted below.

At this point in the process, you have installed the AD DS server role and launched the AD DS Configuration Wizard that will be used to promote the server to be a domain controller. The remaining steps will illustrate the process to add an additional Windows Server 2012 R2 domain controller to an existing domain. The member server that will be promoted has the following attributes:

Domain – cohovines.com
Site – Tokyo
Read Only Domain Controller – No
Global Catalog – Yes
DNS Server – Yes

While the screenshots may vary slightly, the process is largely identical to prior versions of Windows Server.

In the Deployment Configuration screen, specify the domain that the member server will become a domain controller for. You must also provide a set of Domain Admin credentials to complete the promotion process, as shown below.

In the Domain Controller Options step, you should:

Specify if the DC will run the DNS Server service, act as a Global Catalog, or function as a Read Only Domain Controller.
Select the correct AD Site that the DC will be a member of.
Provide a Directory Services Restore Mode (DSRM) password.

Ignore the DNS Options step shown below and any warnings displayed. It is not relevant to adding a domain controller to an existing domain since it is assumed that you have a functional AD forest with working DNS prior to beginning this process.

On the Additional Options step, you can specify the source domain controller to perform initial replication to this server if necessary.
On the Paths step, you may need to modify where the AD DS database (ntds.dit file), transaction logs, or SYSVOL share are stored if your standards dictate. In many cases, accepting the defaults is OK.
Take a moment to review your selections on the Review Options step prior to continuing. You can save a copy of the Windows PowerShell command to promote a domain controller with the options you selected by clicking View script, as shown below.

The Prerequisites Checker will run and attempt to guarantee that the domain controller promotion will succeed. If there are any blocking issues, you will not be able to proceed until the issues are corrected. You may receive warnings about DNS zones, for example, as shown below that can typically be ignored.

Click Install and then monitor the progress on the Results screen. The progress is subtletly updated at the top of the screen as highlighted below.

Whether you leave the AD DS Configuration Wizard open or close it, the server will automatically reboot when the promotion process is complete. Once the server reboots, it will be a member of the domain chosen at the beginning of the wizard and ready to begin functioning as a domain controller.

Forcefully Demote a Domain Controller

If you have a domain controller that is no longer on the network, hasn’t replicated during the forest’s tombstone lifetime, or has been cleaned up in Active Directory via metadata cleanup, you’ll need to do a forced demotion in order to get the server back to a normal state. The procedure to do this varies depending on whether the server in question is running Windows Server 2012 or newer, or if it’s running a prior version of Windows Server.

Windows Server 2012 and Newer (PowerShell)

The easiest way to forcefully demote a Windows Server 2012 (or newer) domain controller is with the Uninstall-ADDSDomainController PowerShell cmdlet.

Launch an elevated PowerShell prompt. You can do this by right clicking the PowerShell icon pinned to the taskbar:

Next, run the following PowerShell command. You will be prompted to provide a local administrator password to be used after the server reboots. The cmdlet will provide some progress information prior to rebooting the server.

Uninstall-ADDSDomainController -ForceRemoval -DemoteOperationMasterRole

Once the server reboots, login with the local administrator password you provided in the previous step. The server is now in a workgroup. If desired, you can safely promote the server back in to service as a domain controller.

Windows Server 2008 R2 and Older (DCPromo)

Versions of Windows prior to Windows Server 2012 do not have a convenient PowerShell cmdlet for forceful demotion of a domain controller. Instead, you must run the DCPromo wizard with a secret parameter.

From the Run dialog, enter “dcpromo /forceremoval”.

If the domain controller holds any FSMO roles, you will receive a warning for each role. Following the completion of this process, you must seize these FSMO roles on new domain controller(s) to ensure that your forest continues to function correctly.


RID Master Warning	PDC Emulator Warning	Infrastructure Master Warning

Domain Naming Master Warning	Schema Master Warning

If the domain controller is a global catalog or a DNS server, you will also be warned. In the case of DNS, ensure that clients aren’t looking to this server for their DNS needs.


DNS Server Warning	Global Catalog Warning

Once any necessary warnings have been displayed, the wizard will start.

You must supply a new local administrator password. This password will be used to login to the server following the completion of the forced demotion process. This password must comply with the domain password policy that applies to the domain controller.

Once you’re sure you want to proceed, click Next to begin the process.

The demotion process will take some time to complete. The progress dialog provides information about what task is currently being performed, but no indication of overall progress.

If you didn’t check Reboot on completion, the wizard will let you know when it’s done.

Once the server reboots, you should immediately seize any FSMO roles that were previously held and perform a metadata cleanup. You can then safely promote the server back to domain controller status if desired.

Installing the Web Application Proxy to Publish AD FS

One of the new additions with Windows Server 2012 R2 was the Web Application Proxy (WAP) feature. If you have deployed AD FS on Windows Server 2008 R2, the WAP replaces the AD FS proxy. WAP is not a direct replacement for AD FS – it is much more.

Once you have installed AD FS, you can install the first WAP server to publish AD FS. You’ll need to have a number of prerequisites in order prior to beginning the installation process:

Server or virtual machine – ensure that the host meets the minimum requirements for Windows Server 2012 R2
Firewall – the WAP will need SSL (TCP443) access to the AD FS federation server. If you are domain joining WAP, it must also have access to domain controllers.
SSL Certificate – install a certificate that matches the AD FS host name (e.g. fs.cohovines.com) or a wildcard certificate in the machine certificate store. You should plan to use a commercially issued certificate from a public certification authority such as DigiCert.

If you will be using the Device Registration Service for Workplace Join, you will need to add subject alternate names (SANs) to your SSL certificate. For each User Principal Name (UPN) suffix that will be supported, you must add a SAN in the format of enterpriseregistration.<UPN Suffix>. For example, in my environment, users have a UPN suffix of cohovines.com. To support Workplace Join, my service communications certificate will need a SAN of enterpriseregistration.cohovines.com.

Once you have all the prerequisite items in place, you can begin installing the first WAP server.

Open Server Manager and click ‘Add roles and features’.
During the Server Selection step of the Add Roles and Features Wizard, shown below, you can elect to install WAP on multiple servers if you have added them to a pool in Server Manager. If you will be installing a server farm, this is a handy time saving feature.

On the next screen, Server Roles, select Remote Access as shown below.

On the Remote Access Role Services screen, select Web Application proxy as shown below.

Complete the wizard to install the WAP service of the Remote Access role.

Once WAP is installed, you can use the Remote Access Management Console to configure WAP to publish AD FS.

Launch the Remote Access Management Console. This Console is accessible from the Tools menu in Server Manager.
Select Web Application Proxy on the left side of the window and then click Run the Web Application Proxy Configuration Wizard.

Enter the FQDN of your AD FS farm as well as a local administrator account on the AD FS servers. This account is only used to setup trust during the configuration process.

If the FQDN of your AD FS farm does not resolve to the correct IP address, you must add the AD FS farm FQDN to the HOSTS file on your WAP server. The HOSTS file is located in c:\windows\system32\drivers\etc.

Select a certificate from the machine’s store for WAP to listen with when proxying to AD FS.

Once the wizard completes, you can publish the WAP server through your firewall on TCP port 443. This completes the tasks necessary to publish AD FS externally with WAP.

Install the First Active Directory Federation Services Farm Member

In this article, we’ll walk through the steps necessary to install the first Windows Server 2012 R2 federation server in an Active Directory Federation Services (AD FS) farm. Subsequent articles will walk through the steps necessary to add additional farm members, install the Web Application Proxy role, and customize AD FS for your organization.

Prior to installing the first server, you’ll need to organize a number of prerequisites for the installation:

Server or Virtual Machine – Ensure that the machine that meets the minimum system requirements and is domain joined
Service Account or Group Managed Service Account – AD FS requires a service account that will be used for Kerberos authentication as well as managing access to security keys across farm members. If you install the service in a domain with at least one Windows Server 2012 domain controller, you can use a Group Managed Service Account (gMSA). Using a gMSA is the recommended approach, and the installation wizard can create and configure a gMSA for you if you have enough access to the directory. If not, create a gMSA in advance for use with AD FS.
Federation Service Name – You will need to choose a DNS name for the federation service. This name will be referenced by clients and relying parties when accessing AD FS. Common hostnames for the federation service include ‘FS’, ‘STS’, and ‘IDP’ (federation service, security token service, and identity provider, respectively). In this example we will use the FS hostname with a fully qualified domain name of fs.cohovines.com.
SSL Certificates – The AD FS service uses three SSL certificates – the service communications certificate, the token signing certificate, and the token decryption certificate. The setup wizard requires that you provide a certificate for service communications, while by default, self signed token signing and token decryption certificates will be generated by AD FS. The service communications certificate is used to secure the HTTPS traffic between clients and AD FS and should be trusted by internal and external clients that will access the service. You should plan to use a commercially issued certificate to ensure trust from a public certification authority such as DigiCert. The common name of the certificate should match the federation service name, e.g. fs.cohovines.com. You can choose whether or not to buy a commercial certificate for token signing and token decryption. Generally speaking, interoperability with third parties is much easier if you choose to buy a commercial certificate for this task. Be sure to get the maximum lifetime possible for the certificate (e.g. 3 years). Changing the certificate later will be an involved process, so it is best to make this design decision up front.

If you will be using the Device Registration Service for Workplace Join, you will need to add subject alternate names (SANs) to your service communications certificate. For each User Principal Name (UPN) suffix that will be supported, you must add a SAN in the format of enterpriseregistration.<UPN Suffix>. For example, in my environment, users have a UPN suffix of cohovines.com. To support Workplace Join, my service communications certificate will need a SAN of enterpriseregistration.cohovines.com. You may also use a wildcard certificate for the service communications certificate.

SQL Server or Windows Internal Database – AD FS uses SQL Server to store server configuration and for two optional features. In lieu of using a full SQL Server installation, AD FS can install the Windows Internal Database (WID), a stripped down version of SQL Server, on each federation server. Prior to installing the first AD FS server, decide whether to use WID or SQL Server for the AD FS farm. If you expect to need to support more than 100 relying parties, or more than five federation servers, Microsoft recommends that you use the full version of SQL Server. Likewise, if you have a need for SAML Artifact Resolution or Token Replay Detection for external claims providers, you must use SQL Server. Review this TechNet Library document for more information on this decision. If you elect to use SQL Server, don’t forget to factor in high availability for SQL Server (e.g. clustering or mirroring).

Once you have completed all of the prerequisite tasks, you can begin installing the first AD FS server.

Open Server Manager and click ‘Add roles and features’.
During the Server Selection step of the Add Roles and Features Wizard, shown below, you can elect to install AD FS on multiple servers if you have added them to a pool in Server Manager. If you will be installing a server farm, this is a handy time saving feature.

On the next screen, Server Roles, select Active Directory Federation Services as shown below. This will automatically add any missing features that AD FS requires to the wizard’s task list.

Proceed through the remainder of the wizard. Once you reach the Results page, shown below, click the ‘Configure the federation service on this server’ hyperlink to begin the AD FS installation process.

The AD FS Configuration Wizard will complete the process of installing AD FS on the server. Since this is the first server in the farm, you will need to provide inputs based on the prerequisite decisions discussed earlier in the article.

On the Welcome page, shown below, ensure that Create the first federation server in the federation server farm is selected at the bottom of the screen.

On the Connect to AD DS page, provide a domain administrator account for installing the federation service. Elevated credentials are required to create a distributed key management object for AD FS in the Domain’s Program Data container. These credentials are only required during the installation process.
On the Specify Service Properties page, shown below, use the decisions made during the prerequisites section of this article to populate the inputs. The SSL Certificate is the Service Communications Certificate. The dropdown list will show any valid certificates that are already imported. You can use the Import button to import a PFX file containing the certificate that AD FS should use. The federation service name must match the certificate selected. Finally, the Federation Service Display Name is displayed on the default login pages and can be easily changed later.

On the Specify Service Account page, shown below, provide details for the service account that the AD FS farm should use. As discussed earlier, a gMSA is the preferred option when possible. If you are running the wizard with sufficient permissions, the wizard can automatically create a gMSA for you. Otherwise, select the second option to specify an existing gMSA or standard domain user account.

On the Specify Database page, provide the details for an external SQL Server if you will be using SQL Server. If you will be using WID, accept the defaults and continue.
A useful option on the Review Options page is the View script button. If you click this button, the AD FS Configuration Wizard will provide the PowerShell script equivalent to the options you chose in the wizard.

The script below shows the equivalent PowerShell syntax for the options selected in the wizard.

Import-Module ADFS

Install-AdfsFarm `
-CertificateThumbprint:"794CAF64196F53F71DF39BE16E4BADDF4FD277C8" `
-FederationServiceDisplayName:"Coho Vineyard" `
-FederationServiceName:"fs.cohovines.com" `
-GroupServiceAccountIdentifier:"COHOVINES\svc_ADFS`$"

Complete the wizard. Once the Results page is shown, you will be able to begin managing the AD FS farm configuration.
To open the AD FS MMC, open the Start screen and search for ‘AD FS’ as shown below. For convenience, you may want to pin the MMC to the Taskbar so it is easily accessible in the future.

In summary, the first AD FS federation server is now installed and ready for configuration, the addition of additional farm members, and publication with the Web Application Proxy. In future articles, we will walk through the steps to perform all three of these tasks.

How to Make a Domain Controller a Global Catalog

Promoting a domain controller to be a global catalog is a simple change that initiates replication of the partial attribute set for each domain in the forest (other than the domain controller’s domain).

To make a domain controller a global catalog, start by launching the Active Directory Sites and Services MMC snap-in. A quick way to launch the snap-in is to run “dssite.msc” from the Run dialog.
Browse to the Site containing the domain controller, and expand the Servers container as shown below.

Double click the domain controller that you will be promoting to a global catalog as shown below.

Open the Properties of the NTDS Settings object.
Check the Global Catalog box shown below.

Starting with the Windows Server 2008 R2 Remote Server Administration Tools (RSAT), you can also promote a domain controller to be a global catalog from AD Users and Computers. Find the Domain Controller's computer account, open the Properties of the object, and click the NTDS Settings button to open the dialog shown above.

You can use LDP to check when the domain controller has completed the initial replication of the partial attribute set. Once this replication completes, it will advertise itself as a global catalog and be accessible to clients.

Run “LDP” from the Run dialog.
Click Connection>Connect… and enter the name of the domain controller you are promoting.
Check the isGlobalCatalogReady attribute of RootDSE as shown below.
If the isGlobalCatalogReady attribute is FALSE, click Connection>Disconnect and then repeat steps two and three until the isGlobalCatalogReady attribute is TRUE.

Change Default Location for Domain Joined Computers

When you join a machine to the domain, by default it will be placed in the Computers container under the root of the domain. This can be undesirable, particularly if you want to apply distinct Group Policy to machines when they are initially joined to the domain. Fortunately, Active Directory lets you change the default location for new Computer accounts. The best way to make this change is with the redircmp tool that is included with Windows Server. For example, to redirect new computers in the cohovines.com domain to an Organizational Unit called NewComputers, run this command:

redircmp "OU=NewComputers,DC=cohovines,DC=com"

Under the covers, the redircmp tool updates an attribute of the domain NC head object called wellKnownObjects. The wellKnownObjects attribute contains a list of well known GUIDs and a distinguished name for each GUID. By using GUIDs, the path to an object can be dynamic without the client needing to be aware of anything other than the GUID for the object it is searching for. In this case, the aa312825-7688-11d1-aded-00c04fd8d5cd GUID is how Active Directory keeps track of the default location for new computer objects. You can use a tool like LDP to look at the wellKnownObjects attribute of the domain as shown below:

Change Default Location for New User Objects

When you create a user account in Active Directory using certain tools, by default the user will be placed in the Users container under the root of the domain. This can be undesirable, particularly if you want to apply distinct Group Policy to these users. Fortunately, Active Directory lets you change the default location for new User accounts. The best way to make this change is with the redirusr tool that is included with Windows Server. For example, to redirect new users in the cohovines.com domain to an Organizational Unit called New Hires, run this command:

redirusr "OU=New Hires,DC=cohovines,DC=com"

Under the covers, the redirusr tool updates an attribute of the domain NC head object called wellKnownObjects. The wellKnownObjects attribute contains a list of well known GUIDs and a distinguished name for each GUID. By using GUIDs, the path to an object can be dynamic without the client needing to be aware of anything other than the GUID for the object it is searching for. In this case, the a9d1ca15-7688-11d1-aded-00c04fd8d5cd GUID is how Active Directory keeps track of the default location for new user objects. You can use a tool like LDP to look at the wellKnownObjects attribute of the domain as shown below:

What Is The Global Catalog?

The Global Catalog (GC) is a critical component of Active Directory, particularly in multi-domain forests. In a multi-domain forest, objects (users, groups, computers, etc.) are spread across each domain. If an application needs to locate a user, for example, and the application does not know what domain the user is located in, then the application would need to contact a domain controller in each domain until the user is located. This approach is highly inefficient, and the Global Catalog is the solution. Domain Controllers that host a copy of the Global Catalog store a partial read-only copy of every object in the forest in the local database. When LDAP queries are submitted on TCP port 3268 (or TCP port 3269 for SSL), a single search can be conducted across all of the objects in the forest.

To conserve space and ensure efficient replication, objects in the Global Catalog are referred to as partial objects because only a subset of the attributes of the object are replicated to the Global Catalog. This subset of attributes is known as the Partial Attribute Set (PAS). Administrators can configure the set of attributes that comprise the PAS by modifying the definition for a given attribute in the Active Directory schema. Many applications that extend the Active Directory schema add their custom attributes to the PAS. Microsoft Exchange Server is a common example of this approach. Exchange adds dozens of attributes to the PAS and subsequently conducts nearly all of its LDAP searches via the Global Catalog.

Special logic in Active Directory ensures that the Global Catalog has a copy of group membership for all universal groups. Consequently, client computers must contact a Global Catalog at logon time to construct a complete token for the user. If the user is located at a site that does not have a Global Catalog, the request must traverse the wide area network (WAN). If a GC is not available (e.g. due to a network outage), the logon attempt will fail. This behavior can be disabled by following the steps in Microsoft Knowledge Base Article 241789. It is important to note however that if this behavior is disabled and a GC cannot be contacted, the user will receive an incomplete security token. Resources secured via universal groups will not be accessible to the user. If your access model uses deny entries in Access Control Lists (ACLs), and a deny entry is specified for a universal group, the deny entry will not be effective because universal group memberships are not reflected in the user’s token.

Historically, the question of what domain controllers should host the Global Catalog was a topic of significant interest during Active Directory design discussions. As WANs have evolved and forest topologies have shrank to have fewer and fewer domains, the need for this discussion has subsided. First and foremost, the GC is not relevant in a single domain forest. If your forest has only one domain, simply make all of your domain controllers GCs. In a multi-domain forest, try to make as many (or all) of your domain controllers GCs if possible. If you have sites that have poor connectivity and the replication overhead of the GC would place a significant burden on the WAN, then you must decide if placing a GC in the site is necessary or not. If the site hosts applications that are dependent on the GC (e.g. Exchange Server), then placing a GC locally is critical. Likewise, if universal group membership is a key component of the access model for applications and services hosted at the site, then placing a GC is likely necessary.

What Are the Five FSMO Roles

Since the first days of Active Directory, the concept of FSMO (Flexible Single Master Operator, pronounced “fizmo”) roles has been a topic of endless discussion amongst IT Professionals. Furthermore, the five roles make for a quick and easy first question in an interview. As Active Directory has evolved over more than a decade, the duties of the FSMO role holders have changed very little, but broad understanding of the duties and optimal placement has not consistently matured.

The five FSMO roles are divided in to two categories: forest-wide and domain-wide. The two forest-wide roles, the Schema Master and the Domain Naming Master exist on a per-forest basis. Meanwhile, the three remaining domain-wide roles - the PDC (Primary Domain Controller) Emulator (PDCe), RID (Relative Identifier) Master, and Infrastructure Master - exist for each domain in the forest. So, for example, in a single domain forest, there are a maximum of five possible FSMO role holders. Meanwhile, in a three domain forest, there are a maximum of eleven FSMO role holders (two forest-wide roles, plus three domain-wide roles multiplied by three domains).

Forest-Wide FSMO Roles

Let’s first examine the forest-wide roles, beginning with the Schema Master. The duties of the Schema Master are well defined and very clear, especially in comparison to some of the other roles. Simply put, any change to the forest’s schema must be made directly on the Schema Master. These changes include adding new classes and attributes as well as modifications to existing classes and attributes (e.g. adding an additional attribute to an existing class or indexing an attribute). It’s important to note a common misconception, however. While any changes to the forest’s schema must be written on the Schema Master, a read-only copy of the schema is stored on every domain controller in the forest.

The second forest-wide role is the Domain Naming Master. The duties of the Domain Naming Master are brief and will not be invoked frequently in most organizations. Any time an administrator adds a new domain to the forest, or removes an existing domain, the Domain Naming Master is called upon. Similarly, adding or removing an application partition is also dependent on the Domain Naming Master.

Application Partitions were added to Active Directory in Windows Server 2003. You can use an application partition to replicate a set of objects to a defined group of domain controllers across the forest. Given the name “application partition”, you can infer that Microsoft was anticipating that many people and software companies would take advantage of the feature. Unfortunately, the only common real-world use of application partitions is Active Directory integrated DNS. Even then so, few organizations customize DNS’ use of application partitions beyond the defaults.

Domain-Wide FSMO Roles

The domain-wide FSMO roles are called upon to perform work much more often than the two forest-wide roles we have discussed so far. Let’s begin with the Infrastructure Master – perhaps the most misunderstood and often debated FSMO role. The duties of the Infrastructure Master are narrow and only called upon in a very specific set of circumstances. Simply put, the Infrastructure Master is only relevant when you have a domain with the following characteristics:

· More than one domain in the forest

· All of the domain controllers in the domain are not global catalogs

· Active Directory Recycle Bin is not enabled

If your forest has only one domain, all of the domain controllers in a given domain are global catalogs, or the AD Recycle Bin is enabled, then the Infrastructure Master has no day-to-day duties.

If your domain does not meet the criteria listed above, then the Infrastructure Master has an important task. The Infrastructure Master is responsible for maintaining hidden objects in the directory known as phantoms. Phantoms are used by the Active Directory database to track group members that are not from the local domain and are not present in the local database. If the domain controller is a global catalog, then every object in the forest is present in the database and a phantom is not necessary to track cross-domain group memberships.

Phantoms have a small number of attributes – the objectGUID value of the actual group member in the foreign domain, the group member’s objectSID (security identifier), and the distinguished name (DN) of the group member. Any time an object in another domain is moved or deleted, the phantom must be updated with the correct value or deleted. The Infrastructure Master is responsible for periodically processing each phantom object in the domain and ensuring that it is up-to-date and necessary.

The Infrastructure Master validates phantoms by connecting a global catalog and finding the corresponding object via its objectGUID. The mechanics of contacting a global catalog are why it is important that the Infrastructure Master is not hosted on a global catalog in a multi-domain forest if you have multiple domain controllers in the domain that are not also global catalogs. When the Active Directory Recycle Bin is enabled in a multi-domain forest, the duties of the infrastructure master are performed locally on each domain controller and the placement of the Infrastructure Master is no longer relevant.

Continuing our discussion, the RID Master has a much more straightforward set of duties. The RID Master distributes pools of RIDs – Relative Identifiers – to each writeable domain controller in the domain. Any time a security principal (user, computer, group, etc.) is created on a domain controller, the domain controller uses a RID to construct the security principal’s unique SID (security identifier). Placing the RID Master is not especially complicated – generally a central point in the network that domain controllers can easily contact is ideal.

The final FSMO role in our discussion is the PDC Emulator. The original need for PDC Emulator dates to Windows 2000 and the need to maintain backwards compatibility with Windows NT by way of having a domain controller that acts as the Windows NT Primary Domain Controller. While the fundamental need for this function has long passed, the PDC Emulator has a number of additional tasks that are still critical. The two most common and important tasks that the PDC Emulator continues to perform are time synchronization and password chaining.

In a given domain, the PDC Emulator is the root of the time synchronization hierarchy. All of the other domain controllers in the domain synchronize their clocks with the PDC Emulator (and in turn client computers and member servers synchronize their clocks with their local domain controllers). In a multi-domain forest, the PDC Emulator in the forest root domain serves as the reference for the PDC Emulators in each of the child domains. Ultimately, the PDC Emulator in the forest root domain should be configured to synchronize its clock with an authoritative external time source.

Password chaining is the second duty of interest for the PDC Emulator. Password chaining is important in environments where domain controllers are spread across multiple sites in a Wide Area Network (WAN). In this case, domain controllers attempt to immediately forward password changes and resets to the PDC Emulator. If a user attempts to authenticate, and the authenticating domain controller rejects the user’s password, the domain controller will first attempt to check with the PDC Emulator to see if the PDC Emulator’s copy of the user’s password matches the password the user is attempting to authenticate with.

In addition to these two tasks, the PDC Emulator is also responsible for a number of less frequent tasks such as executing the AdminSDHolder process and authorizing domain controller cloning operations.

Summary

How to Seize a FSMO Role with NTDSUtil

If a domain controller that holds one or more of the five FSMO roles becomes permanently unavailable, you’ll ultimately need to seize the roles to another domain controller. Seizing FSMO roles is not a graceful process and is intended only to be performed when the unexpected occurs. In normal day-to-day operations, if you need to change what domain controller a FSMO role is held by, you should instead transfer the role. In order to seize the RID Master, PDC Emulator, or Infrastructure Master, you’ll need to be logged in as a Domain Admin. To seize the Schema Master or Domain Naming Master, you must be logged in with Schema Admin or Enterprise Admin permissions, respectively.

If you are seizing the RID Master or Schema Master, you must ensure that the domain controller holding either of those roles is never brought back on the network without being forcefully demoted or erased! I recommend that you immediately perform a metadata cleanup of the domain controller in question once the role is transferred.

In this example, we’ll seize the PDC Emulator to a domain controller called coho-chi-adc02. I have provided the commands to seize each of the four other FSMO roles at the conclusion of these steps.

Open an elevated command prompt
Type ntdsutil and press Enter.
Type roles and press Enter.
Type connections and press Enter.
Type connect to server coho-chi-adc02 and press Enter.

Replace coho-chi-adc02 in the previous step with the name of the domain controller you want to seize the FSMO role to.

Type quit and press Enter. Your screen should look similar to the following after this step:

Type Seize PDC and press Enter. You will be prompted to confirm the seizure as shown below. Once you click yes, the seizure process will begin. This will take some time to complete. As a safety mechanism, NTDSUtil will first try to transfer the role. This should timeout and fail and then the actual seizure will occur.

Once the seizure occurs, you will see output similar to the following written to the console. While the output includes an error, the important success message (highlighted in yellow) is also included.

Attempting safe transfer of PDC FSMO before seizure.
ldap_modify_sW error 0x34(52 (Unavailable).
Ldap extended error message is 000020AF: SvcErr: DSID-032105B1, problem 5002 (UNAVAILABLE), data 1722

Win32 error returned is 0x20af(The requested FSMO operation failed. The current FSMO holder could not be contacted.)
)
Depending on the error code this may indicate a connection,
ldap, or role transfer error.
Transfer of PDC FSMO failed, proceeding with seizure ...

Server "coho-chi-adc02" knows about 5 roles
Schema - CN=NTDS Settings,CN=COHO-CHI-ADC01,CN=Servers,CN=Chicago,CN=Sites,CN=Configuration,DC=cohovines,DC=com
Naming Master - CN=NTDS Settings,CN=COHO-CHI-ADC01,CN=Servers,CN=Chicago,CN=Sites,CN=Configuration,DC=cohovines,DC=com
PDC - CN=NTDS Settings,CN=COHO-CHI-ADC02,CN=Servers,CN=Chicago,CN=Sites,CN=Configuration,DC=cohovines,DC=com
RID - CN=NTDS Settings,CN=COHO-CHI-ADC01,CN=Servers,CN=Chicago,CN=Sites,CN=Configuration,DC=cohovines,DC=com
Infrastructure - CN=NTDS Settings,CN=COHO-CHI-ADC01,CN=Servers,CN=Chicago,CN=Sites,CN=Configuration,DC=cohovines,DC=com

To seize the other roles, run the following commands in lieu of “Seize PDC”. If you are seizing multiple roles, you can seize them sequentially without repeating steps one through six:

Domain Naming Master – “Seize naming master”
Infrastructure Master – “Seize infrastructure master”
RID Master – “Seize RID master”
Schema Master – “Seize schema master”

Once you have completed seizing the roles you need, you can close the command prompt. The changes will replicate throughout your forest via normal channels.

Promote a Domain Controller with Windows PowerShell

Windows Server 2012 and newer servers can be promoted to be a domain controller using Windows PowerShell. If you’re running your domain controllers on the Server Core variant of Windows Server, or you simply need to automate the promotion of domain controllers, PowerShell is a great way to quickly complete this task. In this guide, we’ll look at promoting an additional domain controller in to an existing domain. If you need to script the creation of a new forest or child domain, take a look at the Microsoft documentation for Install-ADDSDomainController and Install-ADDSForest.

Launch an elevated Windows PowerShell prompt. On a server with the GUI installed, you can right click the PowerShell shortcut in the taskbar as shown below. On a Server Core server, type “powershell” in to the prompt.

Customize the following PowerShell script to reflect the name of the domain the server will be promoted in to as well as your Directory Services Restore Mode (DSRM) password. This script will promote a global catalog in to a domain called “cohovines.com” and install the Windows DNS Server service on the service.

$domainName = "cohovines.com"
$domainAdminCredential = Get-Credential
$dsrmPassword = (ConvertTo-SecureString -AsPlainText -Force -String "YourDSRMPassword!!")
Install-ADDSDomainController -DomainName $domainName -InstallDns -Credential $domainAdminCredential -SafeModeAdministratorPassword $dsrmPassword

The server will automatically reboot once prerequisites are installed and promotion has completed.

Active Directory, 5th Edition

I’ve been remiss in posting anything here the past six months as my weekends have been consumed with an update to my book, Active Directory, 4th Edition. The writing and technical reviews of the fifth edition are complete, thanks to Joe Richards, Mark Parris, and Mark Morowczynski. We’ve now moved in to the production cycle and a copy editor is busy fixing up my writing to make the book a polished all-around easy-to-read product. Meanwhile, the illustrators will soon be busy with the artwork – figures, diagrams, etc. The final book is now available!

So, to summarize, Active Directory, 5th Edition is now available:

The eBook is available from O’Reilly here.
The printed book is available from O’Reilly here.
The eBook is available via Safari Books Online at http://my.safaribooksonline.com/9781449361211?portal=oreilly&cid=orm-cat-readnow-9781449361211.
The printed book is available for from Amazon.com at http://www.amazon.com/gp/product/1449320023/ref=as_li_ss_tl?ie=UTF8&tag=briandesmonsb-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=1449320023.

Signing Active Directory, 5th Edition Books at TechEd North America

I’ll be at TechEd North America in New Orleans this week. On Monday, June 3rd from 6:00 to 6:30 PM, I’ll be at the O’Reilly/Microsoft Press booth, booth #511 signing copies of my new book – Active Directory, 5th Edition. If you can’t stop by then, I’ll be at the Access and Information Protection in the Microsoft Solutions Experience Monday from 12PM to 2PM and Tuesday from 12PM to 2:30PM. I’ll also be at the Ask The Experts evening event on Tuesday evening.

Cisco ACE Sample Configuration for Exchange 2010

Cisco’s ACE appliances and modules are something that I see constantly at customers. Unfortunately, Cisco’s application specific documentation is rather lacking. There’s a rather simplistic sample config at http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/App_Networking/Exchange_VSphere_UCS_NetApp.html#wp345264, but, that doesn’t really have everything you need. The folks at F5 on the other hand have extremely well documented application guides for their hardware and that’s one of the reasons I usually send customers to F5 first. The contents of this post are essentially the same for ACE appliances and ACE modules.

In any case, the rest of this post is a working sample configuration for the topology below. A thread on a discussion alias prompted me to clean this up and post it.

In our sample configuration, we’ll configure the load balancer in a one-armed configuration with Source NAT (SNAT). Clients will access services via the mail.contoso.com and autodiscover.contoso.com URLs. In addition, clients who go to a non SSL URL or go to the root instead of /owa will be redirected.

Before we get started, a few pre-requisites:

You should have a working context on your ACE appliance/module with resources allocated.
Your CAS servers should have static ports configured as described here.
Your SSL certificate and the necessary intermediate and root certificates should be installed on the load balancer.
A VIP will need to be allocated. We’ll use 192.168.100.200 in this sample
If you’re expecting more than ~65K client connections, you’ll need to use more than one IP in the SNAT pool. This example assumes one is enough. We’ll use 192.168.100.199 in this sample.

The entire config is posted below, but, first, I wanted to speak to a few specific elements and why they’re here:

crypto chaingroup DigiCert cert DigiCertRootCA cert DigiCertIntermediateCA cert mail_contoso_com	This creates a valid SSL certificate chain
serverfarm host Exchange-CAS-RPC predictor leastconns probe TCP135 probe TCP60000 probe TCP60001 fail-on-all rserver CAS01 inservice rserver CAS02 inservice	Here we’re validating the availability of the RPC ports on the CAS server. The “fail-on-all” keyword is key here. This makes sure that if any of the three services are unavailable, the server is removed from the farm
parameter-map type http Exchange-OWA case-insensitive persistence-rebalance set header-maxparse-length 16384 set content-maxparse-length 8192	There are three things going on here: We’re making URL matching case insensitive persistence-rebalance makes sure that each HTTP request is evaluated individually, and that sticky cookies are inserted only on the first request The max parse lengths define how far into a request the ACE looks for cookies, headers, and so forth. Without this, you’ll likely see issues with partially loaded images and random session timeouts. It’s possible that you’ll need to extend the numbers here.
sticky ip-netmask 255.255.255.255 address source Exchange-CAS-RPC timeout 7200 replicate sticky serverfarm Exchange-CAS-RPC	Here we define source IP stickiness. This is used for the RPC services. Warning: If you have source NAT upstream (such as in a network merger scenario) where many clients are appearing to come from the same IP, this will cause load balancing to not be even.
sticky http-cookie Exchange-Sticky Exchange-CAS-HTTPS-Cookie cookie insert browser-expire replicate sticky serverfarm Exchange-CAS-HTTPS	Here we create a cookie valid for the life of the browser session to ensure that OWA and ECP sessions go to the same CAS server.
action-list type modify http Exchange-CAS-HTTP header insert request X-Forwarded-For header-value "%is"	This enables us to insert the client’s original IP as an additional HTTP header so that IIS logs can be correlated to a specific client.
policy-map type loadbalance first-match Exchange-CAS-HTTPS match OWA http url /owa.* sticky-serverfarm Exchange-CAS-HTTPS-Cookie action Exchange-CAS-HTTP ssl-proxy client Exchange-CAS match ECP http url /ecp.* sticky-serverfarm Exchange-CAS-HTTPS-Cookie action Exchange-CAS-HTTP ssl-proxy client Exchange-CAS match EWS http url /ews.* sticky-serverfarm Exchange-CAS-HTTPS-Cookie action Exchange-CAS-HTTP ssl-proxy client Exchange-CAS match ActiveSync http url /Microsoft-Server-ActiveSync.* sticky-serverfarm Exchange-CAS-HTTPS-AuthZHeader action Exchange-CAS-HTTP ssl-proxy client Exchange-CAS match OutlookAnywhere http header User-Agent header-value "MSRPC" sticky-serverfarm Exchange-CAS-HTTPS-AuthZHeader action Exchange-CAS-HTTP ssl-proxy client Exchange-CAS class Exchange-CAS-HTTPS-RootRequest serverfarm Exchange-OWA-REDIRECT class class-default sticky-serverfarm Exchange-CAS-HTTPS-SourceIP action Exchange-CAS-HTTP ssl-proxy client Exchange-CAS	This policy map enables SSL decryption, inspection of the URL, and application of the correct load balancing action and stickiness.

crypto chaingroup DigiCert
  cert DigiCertRootCA
  cert DigiCertIntermediateCA
  cert mail_contoso_com

access-list all line 10 extended permit ip any any 
access-list all line 20 extended permit icmp any any 

probe https Exchange-OWA
  interval 30
  ssl version all
  request method get url GET /owa/auth/logon.aspx
  expect status 400 404
probe tcp TCP135
  description RPC Endpoint Mapper
  port 135
  interval 30
  connection term forced
probe tcp TCP60000
  description RPC Client Access
  port 60000
  interval 30
  connection term forced
probe tcp TCP60001
  description Address Book Service
  port 60001
  interval 30
  connection term forced

rserver host CAS01
  ip address 192.168.100.101
  inservice
rserver host CAS02
  ip address 192.168.100.102
  inservice
rserver redirect OWA-SSL-REDIRECT
  webhost-redirection https://mail.contoso.com/owa 302
  inservice

serverfarm host Exchange-CAS-HTTPS
  predictor leastconns
  probe Exchange-OWA
  rserver CAS01 443
    inservice
  rserver CAS02 443
    inservice
serverfarm host Exchange-CAS-RPC
  predictor leastconns
  probe TCP135
  probe TCP60000
  probe TCP60001
  fail-on-all
  rserver CAS01
    inservice
  rserver CAS02
    inservice
serverfarm redirect Exchange-OWA-REDIRECT
  rserver OWA-SSL-REDIRECT
    inservice

parameter-map type http Exchange-OWA
  case-insensitive
  persistence-rebalance
  set header-maxparse-length 16384
  set content-maxparse-length 8192
parameter-map type ssl SSL_PARAMS
  cipher RSA_WITH_RC4_128_MD5
  cipher RSA_WITH_RC4_128_SHA
  cipher RSA_WITH_3DES_EDE_CBC_SHA

sticky ip-netmask 255.255.255.255 address source Exchange-CAS-RPC
  timeout 7200
  replicate sticky
  serverfarm Exchange-CAS-RPC
sticky http-cookie Exchange-Sticky Exchange-CAS-HTTPS-Cookie
  cookie insert browser-expire
  replicate sticky
  serverfarm Exchange-CAS-HTTPS
sticky http-header Authorization Exchange-CAS-HTTPS-AuthZHeader
  timeout 7200
  replicate sticky
  serverfarm Exchange-CAS-HTTPS
sticky ip-netmask 255.255.255.255 address source Exchange-CAS-HTTPS-SourceIP
  timeout 7200
  replicate sticky
  serverfarm Exchange-CAS-HTTPS

action-list type modify http Exchange-CAS-HTTP
  header insert request X-Forwarded-For header-value "%is"

ssl-proxy service Exchange-CAS
  key mail_contoso_com
  cert mail_contoso_com
  chaingroup DigiCert
  ssl advanced-options SSL_PARAMS

class-map match-any Exchange-CAS-HTTPS
  2 match virtual-address 192.168.100.200 tcp eq https
class-map type http loadbalance match-any Exchange-CAS-HTTPS-RootRequest
  2 match http url /
class-map match-any Exchange-CAS-RPC
  2 match virtual-address 192.168.100.200 tcp eq 60001
  3 match virtual-address 192.168.100.200 tcp eq 60000
  4 match virtual-address 192.168.100.200 tcp eq 135
class-map match-any Exchange-OWA-REDIRECT
  2 match virtual-address 192.168.100.200 tcp eq www
class-map type management match-any mgmt-cm
  2 match protocol https any
  3 match protocol snmp any
  4 match protocol ssh any
  5 match protocol icmp any

policy-map type management first-match mgmt-pm
  class mgmt-cm
    permit

policy-map type loadbalance first-match Exchange-CAS-HTTPS
  match OWA http url /owa.*
    sticky-serverfarm Exchange-CAS-HTTPS-Cookie
    action Exchange-CAS-HTTP
    ssl-proxy client Exchange-CAS
  match ECP http url /ecp.*
    sticky-serverfarm Exchange-CAS-HTTPS-Cookie
    action Exchange-CAS-HTTP
    ssl-proxy client Exchange-CAS
  match EWS http url /ews.*
    sticky-serverfarm Exchange-CAS-HTTPS-Cookie
    action Exchange-CAS-HTTP
    ssl-proxy client Exchange-CAS
  match ActiveSync http url /Microsoft-Server-ActiveSync.*
    sticky-serverfarm Exchange-CAS-HTTPS-AuthZHeader
    action Exchange-CAS-HTTP
    ssl-proxy client Exchange-CAS
  match OutlookAnywhere http header User-Agent header-value "MSRPC"
    sticky-serverfarm Exchange-CAS-HTTPS-AuthZHeader
    action Exchange-CAS-HTTP
    ssl-proxy client Exchange-CAS
  class Exchange-CAS-HTTPS-RootRequest
    serverfarm Exchange-OWA-REDIRECT
  class class-default
    sticky-serverfarm Exchange-CAS-HTTPS-SourceIP
    action Exchange-CAS-HTTP
    ssl-proxy client Exchange-CAS
policy-map type loadbalance first-match Exchange-CAS-RPC
  class class-default
    sticky-serverfarm Exchange-CAS-RPC
policy-map type loadbalance http first-match Exchange-OWA-REDIRECT
  class class-default
    serverfarm Exchange-OWA-REDIRECT

policy-map multi-match vlan100
  class Exchange-OWA-REDIRECT
    loadbalance vip inservice
    loadbalance policy Exchange-OWA-REDIRECT
  class Exchange-CAS-RPC
    loadbalance vip inservice
    loadbalance policy Exchange-CAS-RPC
    loadbalance vip icmp-reply active
    nat dynamic 1 vlan 1000
  class Exchange-CAS-HTTPS
    loadbalance vip inservice
    loadbalance policy Exchange-CAS-HTTPS
    loadbalance vip icmp-reply active
    nat dynamic 1 vlan 1000
    appl-parameter http advanced-options Exchange-OWA
    ssl-proxy server Exchange-CAS

interface vlan 100
  ip address 192.168.100.10 255.255.252.0
  access-group input all
  nat-pool 1 192.168.100.199 192.168.100.199 netmask 255.255.255.255 pat
  service-policy input mgmt-pm
  service-policy input vlan100
  no shutdown

ip route 0.0.0.0 0.0.0.0 192.168.100.1

Setting Static Ports for Exchange Client Access

If you are deploying Exchange in an environment with load balancers or firewalls which aren’t able to handle dynamic RPC port ranges, chances are you’ll be defining static ports for the RPC Client Access Service and the Address Book Service on each CAS server. If you’re using Public Folders, you’ll want a third static port on the Mailbox servers hosting Public Folders. I typically use these ports for this:

RPC Client Access Service – TCP 60,000
Address Book Service – TCP 60,001
RPC Client Access (Public Folders) – TCP 60,002

For the first two, I’ve included a script below which makes quick work of setting the ports. Just run it on the CAS server to make the required changes.

param([int32]$MAPIPort = 60000, [int32]$AddressBookPort = 60001, [bool]$RestartServices = $true)
# ==============================================================================================
# NAME: Configure Exchange Static Ports
# 
# AUTHOR: Brian Desmond, brian@briandesmond.com
# DATE  : 4/9/2012
# 
# COMMENT: 
# 
# ==============================================================================================

Set-PSDebug -Strict:$true

function CheckProcessElevation()
{
    $identity  = [System.Security.Principal.WindowsIdentity]::GetCurrent()
    $principal = New-Object System.Security.Principal.WindowsPrincipal($identity)

    return $principal.IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator)
}

function CreateRegistryKeyIfNecessary([string]$path)
{
    if (Test-Path -Path $path)
    {
        return
    }
    else
    {
        [void](New-Item -Path $path)
    }
}

Function Test-RegistryValue($regkey, $name) 
{
    Get-ItemProperty $regkey $name -ErrorAction SilentlyContinue | Out-Null  
    $?
}

function CreateOrUpdateRegistryValue([string]$path, [string]$valueName, [Microsoft.Win32.RegistryValueKind]$valueType, $value)
{
    if ((Test-Path -Path $path) -ne $true)
    {
        CreateRegistryKeyIfNecessary $path
    }
    
    if ((Test-RegistryValue $path $valueName) -eq $false)
    {
        [void](New-ItemProperty -Path $path -Name $valueName -PropertyType $valueType -Value $value)
    }
    else
    {
        [void](Set-ItemProperty -Path $path -Name $valueName -Value $value)
    }
}

if ((CheckProcessElevation) -eq $false)
{
    Write-Warning "Script must be run from an elevated prompt. Exiting..."
    exit 1
}

$domtParamsPath = "HKLM:\System\CurrentControlSet\Services\MSExchangeAB\Parameters"
$momtParamsPath = "HKLM:\System\CurrentControlSet\Services\MSExchangeRPC\ParametersSystem"

Write-Host "Setting Address Book Service Port to $($AddressBookPort)"
CreateOrUpdateRegistryValue $domtParamsPath "RpcTcpPort" "String" $AddressBookPort.ToString()
Write-Host "Setting RPC Client Access Port to $($MAPIPort)"
CreateOrUpdateRegistryValue $momtParamsPath "TCP/IP Port" "DWord" $MAPIPort

if ($RestartServices)
{
    Write-Host "Restarting Services..."
    Restart-Service -Name "MSExchangeAB" -Confirm:$false
    Restart-Service -Name "MSExchangeRPC" -Confirm:$false
}
Write-Host "Complete." -ForegroundColor Green

If you’re looking to restrict the port used for Public Folder access, you’ll need to do this in addition to the script above. The registry setting you want is below:

Key: “HKLM\System\CurrentControlSet\Services\MSExchangeRPC\ParametersSystem”

Value Name: "TCP/IP Port”

Value Type: REG_DWORD

Value Data: “60002” (decimal)

Using Device Manager Remotely

If you have servers running the Server Core version of Windows Server, you may need to look at what devices and drivers are installed. While you can accomplish this task with various command line tools, the command line tools are difficult to use. Instead, with a bit of configuration work, you can use the familiar Device Manager GUI remotely.

To do this, you’ll need to configure a Group Policy setting for the affected servers:

Computer Configuration \ Policies \ Administrative Templates \ System \ Device Installation \ "Allow remote access to the Plug and Play interface”

Set the value to enabled:

If you don’t do this, you’ll get an error similar to the following:

---------------------------
Device Manager
---------------------------
Unable to access the computer SERVER01
Make sure that this computer is on the network, has remote administration enabled, and is running the "Plug and Play" and "Remote registry" services.
The error was: Access is denied.

---------------------------
OK
---------------------------

Once you’ve got things in place and the policy is effective, you can use Computer Management to target a remote machine and use the Device Manager snap-in:

---------------------------
Device Manager
---------------------------
Device Manager is running in read-only mode because you are running it on a remote computer. To uninstall devices or to change device properties or drivers, you must run Device Manager on the computer where you wish to make changes.
---------------------------
OK
---------------------------

You won’t be able to make changes, but, you’ll certainly be able to view all of the relevant details.

Script to Ping a List of Servers with PowerShell

I needed to quickly get the IP addresses of about 100 servers from their names. I pasted all the servers into a text file, one per line, and ran the following loop:

$servers = Get-Content .\serverList.txt
$ping = New-Object System.Net.NetworkInformation.Ping

foreach($s in $servers)
{
    $("$s,$($ping.Send($s).Address)")
}

This loop outputs a comma delimited list of ServerName,IP to the window like this:

TEST-SF6,10.12.3.96
W2003TEST,10.1.34.80
W2003TEST2,10.8.51.27

I pasted the list into a new email in Outlook, highlighted it, and then used the Convert Text to Table feature in Word (and Outlook):

Word turned my pasted CSV list into a nice table and I sent it off.

Thoughts on Building a Server Image

Repeatable, consistent, and predictable are three things that add an incredible amount of value in IT, and building servers from a base image is one way to deliver on this. I was just replying to a thread on a discussion alias where the person who started the thread had reviewed a blog post (http://www.jasonsamuel.com/2010/05/07/how-to-build-a-vmware-vsphere-vm-template-for-windows-server-2008-r2/) on how to build such an image for VMWare. I and a number of people disputed the recommendations made in the referenced blog post in addition to the various other things the individual who started the thread was planning to install in his image/template.

At a high level, the most important thing from my reply, I think, is that you should not be customizing a server for it to be convenient to your work style. The server is there for a purpose driven task. You shouldn’t even be connected to it via Remote Desktop (or sitting at the console) unless you’re troubleshooting a problem which can only be investigated from the desktop. What this means is that all the little utilities and tweaks you have on your desktop should stay on your desktop. Things like PDF readers, Internet Explorer customizations, screensavers and colors, and taskbar preferences, etc. First and foremost, many of these tweaks are profile specific so when you login with a domain account later, after running sysprep, the tweaks will be gone unless you push them into the default profile and in turn push them on to all users. Secondly, when you move on to the next big opportunity, your successor shouldn’t be expected to inherit and adapt (or spend weeks undoing) your personal preferences.

As far as system settings (e.g. page files, network settings, etc.), tweaking or disabling things just because some random guy on the Internet (including me) told you to is not a great idea. When you install an application from a vendor, be it Microsoft or any third party ISV, chances are they made assumptions in their testing that the OS is in a state relatively close to the default install. When you start disabling services (e.g. Indexing, Print Spooler, etc.) by default in an image, you provide a baseline that doesn’t meet this assumption. Rather than customizing by default, customize for specific applications. The settings in an image should be the ones required to operate at a minimum level of functionality on your network (e.g. maybe you need some custom DNS search suffixes to join the domain or settings to meet security standards). This extends to most any system level default. When you’re looking at changing a default setting, I’d first stop and ask yourself “why?”. What’s the reason this is being changed? Next, consider whether or not it should be or needs to be hardcoded in the image or if you can simply apply that configuration change via Group Policy. Anything hardcoded will require you to come back and update and re-test, and re-release the image when the value needs to be changed, whereas a Group Policy setting is easily tweaked centrally.

Inevitably there are various tools, gadgets, trinkets, etc., which make troubleshooting easier. My experience is that a great many of these tools don’t require installation and will simply run from a network share. Rather than caching tools locally on each server, or installing individual copies, put them out on a share that you can access from any machine. This way you only need to refresh one location when a tool gets updated and you also aren’t installing essentially random software on servers on an as-necessary basis. As soon as those installs aren’t consistent across all servers, you start permuting your test matrix. Personally the only thing I consistently install on a server build is Netmon or Wireshark and occasionally BgInfo (Sysinternals).

Active Directory, 4th Edition Updates

Over the past couple years, readers have identified a number of mistakes that unfortunately made it through the edit cycles for Active Directory, 4th Ed. O’Reilly recently launched a process by which authors can make updates to the source files that they use to produce eBooks and print conventional paper books on demand. I took advantage of this a few weeks ago and I resolved all of the errata which were reported as well as a couple I found myself. Here’s the quick summary on where the updated text can be found:

Print Copies - If you’ve bought a print copy, you’ll need to look at the notes I made on the errata page. However, as O’Reilly is now doing print on demand for this title, the updates will trickle out into the supply chain over time and newly purchased books will be updated. Obviously this timeline is highly dependent on how much inventory is sitting in warehouses.

eBooks - If you bought any of the various eBook formats O’Reilly offers in their web store – PDF, mobi, and ePub – then you’ll be able to login to your account and pull an updated copy down. I’m told you will also be getting an email sometime soon (if it hasn’t gone out already) notifying you of this as well. If you purchased the book for Kindle from Amazon, Amazon doesn’t have a mechanism to push updated content to your Kindle, so you won’t get an update. This also applies if you bought the book for iPhone/iPad from the Apple bookstore. The iPhone/iPad “app” version of the book is also not going to get updated due to the shift to the native Apple Bookstore.

Active Directory Group Scopes and Group Nesting

Dating to the early days of Windows NT is a discussion of what group scope to choose when creating a new group in Active Directory. There are a plethora of acronyms and time tested practices that administrators sometimes turn to, but, I usually recommend a simple approach. In many organizations, I suggest that the time spent debating this topic could be better focused somewhere more important.

There are three group scopes available:

Domain Local
Global
Universal

The scope primarily affects four things:

The exposure of the group across trusts, and the ability to add group members from other domains or forests.
The number of bytes the group consumes in the user’s logon token. This is important in large organizations that have token bloat problems.
In large highly-distributed multi-domain forests that have domain controllers dispersed around the world, and replication traffic poses a network concern, universal group membership changes are replicated to every global catalog.
In multi-domain forests, if every domain controller is not a global catalog, logon will fail (by default) if a global catalog cannot be contacted during the logon attempt.

In order to understand how the scope of a group affects your ability to nest groups (that is, make one group a member of another group), first study the rules for whether or not a group from one domain can be used in another domain:

Domain local – only useable within the domain that the group was created in. Cannot be accessed via a trust.
Global – useable in the domain the group was created in, or in any domain that trusts the domain the group is in.
Universal – useable in the domain the group was created in, or in any domain or forest that trusts the domain the group is in.

As you consider the rules above, you can see why you cannot nest a Domain Local group in a Global or Universal group. Simply put, Global and Universal group membership is accessible across trusts, but domain local group membership is not. So, if you were to nest a Domain Local group in a Global or Universal group, the full group membership would not be accessible across the trust. Fortunately, Active Directory enforces these rules for us. You can keep track of these rules by referencing the table below:

Group scope	Can contain users and computers from		Can contain domain local groups from
Group scope	Same domain	Different domain	Same domain	Different domain
Domain local groups	Yes	Yes	Yes	No
Domain global groups	Yes	No	No	No
Universal groups	Yes	Yes	No	No

The next table highlights the rules that apply to global and universal groups.

Group scope	Can contain domain global groups from		Can contain universal groups from
Group scope	Same domain	Different domain	Same domain	Different domain
Domain local groups	Yes	Yes	Yes	Yes
Domain global groups	Yes	No	No	No
Universal groups	Yes	Yes	Yes	Yes

Add Office 365 Exchange Online to your PowerShell Profile

The Exchange Online component of Office365 exposes a variant of the Exchange Management Shell that you’d normally use if you were managing an on-premises Exchange 2010 organization. Connecting to it requires a few steps which are documented here. I’ve been pasting in the three commands one at a time now for months and it’s gotten rather annoying. A bit of research reveals that you can add custom PowerShell code that is available anytime you launch a shell by modifying your PowerShell profile. You can read more about the various profiles you can modify here, but, I decided to simply modify the one specific to my user account. To do this, open a new PowerShell window and run this command:

notepad $PROFILE

If you haven’t done this before, notepad will prompt you to create a new file. Plug this code in the resultant file:

function Connect-ExchangeOnline
{
  $LiveCred = Get-Credential
  $global:Session365 = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
  
  Import-PSSession $global:Session365
}

function Disconnect-ExchangeOnline
{
  Remove-PSSession $global:Session365
}

Save and restart PowerShell, and you’ll be able to run Connect-ExchangeOnline to connect to Exchange Online in one easy step.

Script to Collect Hardware Inventory Data

The VBScript below will collect a number of hardware demographics from machines and output them to a CSV file. These demographics include:

Host Name
Serial Number
Make
Model
BIOS Version
Operating System
CPU
Memory (MB)
Disk Drives

You’ll need to supply an input file with one hostname or fqdn per line. You can configure the input and output files on lines 14 and 15 of the script.

'==========================================================================
' NAME: Script to Collect Serial Number, Make, Model, Color, etc.
'
' AUTHOR: Brian Desmond
' DATE  : 10/22/2006
' DATE    : 7/16/2007 - added cpu, memory, disk, and error handling
'==========================================================================

Option Explicit

Const wbemFlagReturnImmediately = &h10
Const wbemFlagForwardOnly = &h20

Const PATH_TO_INPUT = "Machines.txt"
Const PATH_TO_OUTPUT = "MachineInventory.csv"

Dim fso
Set fso = WScript.CreateObject("Scripting.FileSystemObject")

Dim shl
Set shl = WScript.CreateObject("WScript.Shell")

Dim input
Set input = fso.OpenTextFile(PATH_TO_INPUT)

Dim output
Set output = fso.CreateTextFile(PATH_TO_OUTPUT, True)

output.WriteLine "Hostname,Serial Number,Make,Model,BIOS Version,Operating System,CPU,Memory (MB),Disk Drives"

Dim wmiService
Dim wmiResults

Dim hostname
Dim make
Dim model
Dim biosversion
Dim operatingSystem
Dim serialNumber
Dim cpu
Dim memory
Dim drives

Dim line
Dim exec
Dim pingResults 
While Not input.AtEndOfStream
    line = input.ReadLine
    hostname = ""
    make = ""
    model = ""
    biosversion = ""
    operatingSystem = ""
    serialNumber = "" 
    cpu = ""
    memory = ""
    drives = ""
    
    Set exec = shl.Exec("ping -n 2 -w 1000 " & line)
    pingResults = LCase(exec.StdOut.ReadAll)
    
    If InStr(pingResults, "reply from") Then
        WScript.Echo "Reply From: " & line 
        On Error Resume Next 
        
        Set wmiService = GetObject("winmgmts:\\" & line & "\root\CIMV2")
    
        If Not Err.Number = 0 Then
            output.WriteLine line & ",Error: " & Err.Description
            WScript.Echo line & ",Error: " & Err.Description
            On Error GoTo 0
        Else
            On Error GoTo 0
            hostname = line

            Set wmiResults = wmiService.ExecQuery("SELECT * FROM Win32_BIOS", "WQL", wbemFlagReturnImmediately + wbemFlagForwardOnly)
        
            Dim item
            For Each item In wmiResults
                serialNumber = Trim(item.SerialNumber)
                biosversion = Trim(item.SMBIOSBIOSVersion)        
            Next
            
            Set wmiResults = wmiService.ExecQuery("SELECT * FROM Win32_ComputerSystem", "WQL", wbemFlagReturnImmediately + wbemFlagForwardOnly)
            
            For Each item In wmiResults
                make = Trim(item.Manufacturer)
                model = Trim(item.Model)
            Next
            
            Set wmiResults = wmiService.ExecQuery("SELECT * FROM Win32_OperatingSystem", "WQL", wbemFlagReturnImmediately + wbemFlagForwardOnly)
            
            For Each item In wmiResults
                operatingSystem = Trim(item.Name)
                operatingSystem = Split(operatingSystem, "|")(0)
                memory = Round(Trim(item.TotalVisibleMemorySize) / 1024, 2)
            Next
    
            Set wmiResults = wmiService.ExecQuery("SELECT * FROM Win32_Processor", "WQL", wbemFlagReturnImmediately + wbemFlagForwardOnly)
    
            For Each item In wmiResults
                cpu = Trim(item.Name)
            Next
            
            Set wmiResults = wmiService.ExecQuery("SELECT * FROM Win32_LogicalDisk WHERE DriveType=3", "WQL", wbemFlagReturnImmediately + wbemFlagForwardOnly)
    
            For Each item In wmiResults
                drives = drives & Trim(item.DeviceID) & " " & Round(Trim(item.Size) / (1024^2), 2) & ";"
            Next
            
            output.WriteLine hostname & "," & serialNumber & "," & make & "," & model & "," & biosversion & "," & operatingSystem & "," & cpu & "," & memory & "," & drives
            WScript.Echo hostname & "," & serialNumber & "," & make & "," & model & "," & biosversion & "," & operatingSystem & "," & cpu & "," & memory & "," & drives
        End If
    Else
        output.WriteLine line & ",No Response"
        WScript.Echo line & ",No Response"
    End If 
Wend 

output.Close
input.Close

Set wmiService = Nothing
Set wmiresults = Nothing

Configuring the Dell/Quest Free/Busy Connector for Lotus Notes and Exchange - Part 1

The goal of this post is to introduce the Quest Free/Busy (F/B) connector that comes with Coexistence Manager for Notes (CMN), discuss how it works, and discuss the interface with Exchange. In this post we’ll also configure the Quest Web Services and Domino Free Busy Connector Service. Future posts in this series will discuss configuring the remaining components of the CMN F/B Connector. First, let’s take a look at the sample environment we’ll be using for this discussion:

There are three components of the F/B Connector which you’ll need to deploy:

Domino Free/Busy Service – This component is responsible for accepting F/B requests from Exchange users, retrieving, and processing the data from Domino, and returning it to Exchange. This component also includes two web services which run inside IIS:
- Autodiscover implementation
- Exchange Web Services (EWS) implementation
Exchange Free/Busy Service – This component is responsible for accepting F/B requests from Lotus Notes (via QCALCON) for Exchange users, retrieving and processing the data, and returning it to QCALCON.
QCALCON Task – This is a Domino server tasks from Quest which handles requests for Exchange user F/B information. These requests are sent to the Quest Exchange Free/Busy Service.

Quest recommends that you separate the first two components on to two separate servers for performance reasons. They don’t make any data readily available as to when this is necessary, so you’ll need to make a judgment call and do some testing in the lab as to whether or not this is necessary. In a large environment, it’s possible to scale some of the components out behind a load balancer as well. In addition, Quest also recommends physical hardware in lieu of Virtual Machines, although my personal opinion is that given proper resource allocation, this guidance is stuck somewhere in the era of the Notes UI design.

The way Quest integrates Notes F/B data with Exchange is clever, and to understand it, you’ll need to have a bit of background on how Outlook clients (and others) get F/B info. Prior to Exchange 2007, Exchange stored F/B information in Public Folders, and Outlook clients knew where to go in the Public Folder store to find the data. With the desire to move away from Public Folders, this information became available via Exchange Web Services (EWS), also sometimes called the Availability Service (AS). This is a SOAP based web service hosted on the CAS server and accessible via HTTPS. Outlook 2007 and newer knows how to access this endpoint as does Outlook for Mac and various other EWS clients. Exchange 2007 also introduced the ability to provide a means for cross-organization F/B info without any complex public folder replication. The way this works is you define an “availability address space” in Exchange which tells Exchange for a given subdomain, send those F/B requests over to a different AS endpoint. If you’re not familiar, take a look at this post before reading further. This functionality is what Quest leverages.

What Quest has done is re-implement the Autodiscover service as well as the Availability Service such that Exchange thinks it’s talking to another Exchange organization, when in fact it’s actually talking to the Quest Domino F/B server. In Exchange, we define an availability address space for lotus.contoso.com which will resolve (via Autodiscover) to Q-LNFBC01.

Pre Requisites

With the background information out of the way, let’s go ahead and start setting this up. You’re going to need a number of resources:

One to two servers to install the Quest components. For this example, I’ll use the two pictured above.
A Lotus Notes server to install the QCALCON task.
Administrative access to Lotus Notes
Exchange Organization Management level access to Exchange
A standard Domino user ID file and password with mail file.
A standard Exchange mailbox enabled user and password

Install PowerGUI on Q-EXFBC01 and Q-LNFBC01, and then Free/Busy coexistence components. The installers are quite self explanatory, so I won’t walk through those. Be sure to only install “Web Server Components” and “Lotus Notes Components” on the Domino F/B server and the “Exchange Components” on the Exchange F/B server.

Note: It’s possible to separate the Web Server components on to a separate server or set of load balanced servers if you have sufficient demand. For this walk through, I will assume they’re installed on Q-LNFBC01, though.

Configuring the Web Services and Domino Free Busy Connector Service

Once the installations are complete, we’ll use PowerGUI to configure the web services and Domino Free/Busy service.

Launch PowerGUI on Q-LNFBC01.
Browse to PowerGUI\CMN Free/Busy Connector Management\Configure Web Services and Lotus Notes Components in the Navigation Tree.
Select Configuration Wizard from the task pane on the right.
Configure an SMTP domain of lotus.contoso.com. Select autodiscover.lotus.contoso.com.

Note: You must create a DNS A record for autodiscover.lotus.contoso.com which points to the IP of Q-LNFBC01.

Configure the following values for Domino:
- Domino Server Name: LN-ADM01/CONTOSO.
- Domino ID File Path: (browse to the ID file)
- Domino Password: (password to the ID file)

Complete the wizard.
Start the “Quest CMN Domino Free/Busy Connector Service” service.

Note: The domain specified in Step 4 needs to match the Internet address field in your Notes person documents. Chances are your Notes environment is configured to accept mail for *@lotus.contoso.com for mail routing coexistence, but your users have Internet addresses in the form of *@contoso.com. To work around this in CMN, you need to add an SMTP Domain Mapping. To do this, you’ll need to work in PowerShell directly:

Launch the Free Busy Connector Management Shell (Start>All Programs>Quest Software>Quest Coexistence Manager for Notes>Free Busy Connector).
Run this command:

Set-CmnDominoFreeBusyConfig -SmtpDomainMappings "lotus.contoso.com=contoso.com"

Restart the Quest CMN Domino Free/Busy Connector Service.

Next, you’ll need to obtain an SSL certificate for the web services. While it’s possible to use a self signed certificate, your troubleshooting overhead will be substantially minimized if you obtain a proper trusted certificate. To obtain a certificate, you’ll need to generate a Certificate Signing Request (CSR).

Launch Internet Information Services (IIS) Manager (start>run>inetmgr).
Select Q-LNFBC01 in the COnnections tree.
Double click Server Certificates in the center pane.
Select Create Certificate Request in the task pane on the right.
Enter a Common name of autodiscover.lotus.contoso.com and populate the request of the screen as appropriate.
Upload the resultant CSR to your Certificate Authority (I recommend DigiCert if you don’t have a preference).

Once you receive the certificate back from your CA, return to the Server Certificates view in IIS Manager.

Select Complete Certificate Request in the task pane on the right.
Browse to the file you received from your CA and complete the wizard.
Browse to Q-LNFBC01\Sites\Default Web Site in the Connections pane.
Select Bindings in the task pane at right.
Click Add.
Select type https.
Find your SSL certificate in the SSL certificate drop-down.

In the next post in this series, we’ll configure the Exchange Fee/Busy Connector and the Domino QCALCON server task.

Configuring the Dell/Quest Free/Busy Connector for Lotus Notes and Exchange - Part 2

In Part 1 we took at look at the architecture of the Quest Free/Busy (F/B) Connector in Coexistence Manager for Notes (CMN) as well as how Exchange interfaces with it. We also configured the F/B Connector web services and the Domino Free Busy Connector Service. In this post, we’ll configure the Exchange Free Busy Connector Service, the Domino QCALCON task, and the Exchange organization. As a reminder, here’s a copy of our sample environment that will be referenced:

Configuring the Exchange Free Busy Connector

Create a standard mailbox enabled user (e.g. svc_xch_cmn_fb) in Exchange. This will be used by CMN to query Exchange F/B information.
Launch PowerGUI on Q-EXFBC01.
Browse to PowerGUI\CMN Free/Busy Connector Management\Configure Domino Server and Exchange Components.
Launch the Configuration Wizard from the task pane.
- Preferred Exchange server: mail.contoso.com.

Note: This is generally the URL which end users would access your CAS servers with internally such as for OWA. While the PowerGUI UI suggests you should enter a specific CAS server, it is better to enter a load balanced URL or at least the friendly URL listed on your SSL certificate. In this example we will use mail.contoso.com but you should substitute the value most appropriate for your environment.

Domain\Username: CONTOSO\svc_xch_cmn_fb.
Password: (service account password).

Complete the wizard.
Start the Quest CMN Exchange Free/Busy Connector Service service.

Configuring the Exchange Organization

Configuring your Exchange organization is perhaps the easiest part of this project. You’ll simply need to configure an Availability Address Space for lotus.contoso.com. If you’re not familiar with this, take a moment to review this post.

Launch the Exchange Management Shell (EMS).
Run the following PowerShell command:

Add-AvailabilityAddressSpace -ForestName "lotus.contoso.com" -AccessMethod OrgWideFB -UseServiceAccount:$true

Configuring the QCALCON Task

The final server component you’ll need to configure is the QCALCON task. Tasks are background processes of sort in Domino at least to the extent I understand them. You can configure them to either run at startup or at a specific time. For this step, install PowerGUI and the CMN Domino Server Components on LN-ADM01. The task and its configuration files are installed directly in the Domino server folder (e.g. c:\lotus\domino).

Configuring the QCALCON task is quite straight-forward.

Launch PowerGUI.
Browse to PowerGUI\CMN Free/Busy Connector Management\Configure Domino Server and Exchange Components\Advanced\Domino Server Task (QCALCON)
If prompted to browse for the Config File, you’ll find it under your Domino installation folder (e.g. c:\lotus\domino\qcalcon.exe.config).
Select Set Foreign Domain Name in the task pane. Enter mail.box when prompted.
Select Set Exchange Free/Busy Connector host name in the task pane. Enter Q-EXFBC01.
Open your notes.ini file (likely in c:\lotus\domino\notes.ini), and verify that the ServerTask= line includes qcalcon. If it doesn’t, add it to the end of the list.

Note: You may need to provide a fully qualified hostname in step 4.

Once you’ve configured QCALCON, you can start the task.

Launch the Lotus Domino Console (or connect remotely via Domino Administrator)
Run “load qcalcon”. You should see output like this if it’s succesful:

06/26/2011 03:08:55.25 PM [08F4:0005-060C] SchMsgQHandles_New> Opening queues for LWPSCHEDGATEWAY
06/26/2011 03:08:55.25 PM [08F4:0005-060C] SchMsgQHandles_New> InputQ: 121D0h, error = 0h: No error
06/26/2011 03:08:55.25 PM [08F4:0005-060C] SchMsgQHandles_New> OutputQ: 122A8h, error = 0h: No error
06/26/2011 03:08:55.25 PM [08F4:0004-00F0] SchMsgQHandles_New> Opening queues for MAIL.BOX
06/26/2011 03:08:55.25 PM [08F4:0004-00F0] SchMsgQHandles_New> InputQ: 12380h, error = 0h: No error
06/26/2011 03:08:55.25 PM [08F4:0004-00F0] SchMsgQHandles_New> OutputQ: 12450h, error = 0h: No error
06/26/2011 03:08:55 PM QCalCon Server: Starting
06/26/2011 03:08:55 PM QCalCon Server: Version 1.0.3.10
06/26/2011 03:08:55 PM QCalCon Server: Creating queue for mail.box
06/26/2011 03:08:55 PM QCalCon Server: Creating queue for LWPSCHEDGATEWAY
06/26/2011 03:08:55 PM QCalCon Server: Started

Note: If you need to change any of the values in the QCalCon config file, you’ll need to restart the task. To do this, you can issue a “tell qcalcon quit” command in the Lotus Domino Console.

In the next post in this series, we’ll look at configuring the proper documents in the Notes configuration as well as configuring test users in Exchange.

Configuring the Dell/Quest Free/Busy Connector for Lotus Notes and Exchange - Part 3

In Part 1 we took at look at the architecture of the Quest Free/Busy (F/B) Connector in Coexistence Manager for Notes (CMN) as well as how Exchange interfaces with it. We also configured the F/B Connector web services and the Domino Free Busy Connector Service. In Part 2, we configured the Exchange Free Busy Connector Service, the Domino QCALCON task, and the Exchange organization. In this post, we’ll complete the configuration by configuring Lotus Notes as well as building a test user in Exchange and Lotus Notes to validate the configuration. At the end of this post you should have working Free/Busy coexistence between Exchange and Notes.

As a reminder, here’s a copy of our sample environment that will be referenced:

Configuring the Lotus Notes Domain

All of the configuration tasks in this section will be performed in the Domino Administrator tool.

Browse to Configuration > Messaging > Domains.
Select Add Domain on the toolbar.
Populate the Basics tab with the following data:

Domain type: Foreign Domain
Foreign domain name: Exchange

Populate the Mail Information tab with the following data:

Gateway server name: LN-ADM01/CONTOSO.
Gateway mail file name: mail.box.

Populate the Calendar Information tab with the following data:

Calendar system name: LN-ADM01/CONTOSO.
Calendar system: mail.box.

Click Save & Close.

At this point, Domino should begin routing Exchange calendar requests to the QCALCON task and over to Exchange. To test this, we’ll need to configure a couple test users.

Testing the Configuration

We’ll create two test users for this exercise. User George Washington will have mail on Lotus Notes, while user Abraham Lincoln will have mail on Exchange. First, let’s configure Exchange.

Create a Contact in Exchange for George Washington. Specify an External Email Address (targetAddress) of gwashington@lotus.contoso.com.
Create a Mailbox in Exchange for Abraham Lincoln. Ensure the primary email address for Abraham Lincoln is alincoln@contoso.com.

In step 1, we’ve created an object which will be used for routing mail as well as for ensuring that the availability service redirects free/busy information to the Quest components. Next, let’s add these users to Lotus Notes.

Switch to the People & Groups tab in Domino Administrator.
Browse to Domino Directories > CONTOSO’s Directory > People.
Click Add Person.
Populate the Basics tab as shown below:

Populate the Miscellaneous tab as shown:

Click Save & Close.

Next, we need to register George Washington with Notes.

In People & Groups, expand People on the right under Tools, and click Register….
Populate the Basics tab as shown. Be sure to select LN-SRV01 by clicking Registration Server….

Check Advanced in the lower left
Switch to the Address tab.
Populate the Address tab as shown:

Click Register.
Press F9 to refresh the People view.

What we’ve done is created a Person document for Abraham Lincoln which forward to Exchange and specifies the Foreign Domain created earlier for calendaring. We’ve also created a full fledged mailbox enabled user for George Washington in Lotus Notes.

Testing

Populate Abraham Lincoln’s calendar with a few appointments in Exchange. In Lotus Notes, populate George Washington’s calendar with a few appointments as well.

Open George Washington’s person document from the People view in the NAB.
Click Open Mail File… on the toolbar.
Click Mail and then Switch to Calendar in the upper left of George Washington’s mail file to open the calendar.
Create a few appointments.

In Exchange, invite George Washington to a meeting using Outlook. Verify the free/busy information is displayed (e.g. no hash marks). In Lotus Notes, invite Abraham Lincoln to a meeting. verify that the Find Available Times tab shows free/busy information. Be advised that in both cases it may take a few moments for data to become available.

Troubleshooting

There are a number of places you can look to for troubleshooting information depending on where you think the problem lies. All of the Quest components log useful information to a file:

QCALCON (Domino to Exchange lookups) – c:\lotus\domino\qcalcon.exe.log.
Exchange Free/Busy Connector Service (Domino to Exchange lookups) – C:\Program Files (x86)\Quest Software\Quest Coexistence Manager for Notes\Free Busy Connector\ExchangeFreeBusyService.exe.log.
Domino Free/Busy Connector Service (Exchange to Domino lookups) – C:\Program Files (x86)\Quest Software\Quest Coexistence Manager for Notes\Free Busy Connector\DominoFreeBusyService.exe.log.

One additional useful tip surrounding the Quest components deals with caching. Both components keep requests cached in memory for 5 minutes by default. When you're troubleshooting, this can be problematic as you must restart the service each time you change a user in Notes or Exchange to see the effect. You can go in the Advanced configuration of either service in PowerGUI and tweak the cache lifetimes to "0" to disable caching. Just be sure to return the cache to the default values once you put the environment in production.

The Outlook availability service logging is also quite useful. You can enable that by going to Options>Advanced>Other>Enable Troubleshooting Logging. Restart Outlook and create a new meeting request. You’ll find logging information in %temp%\olkas which will include the exact errors and XML returned by the Quest components.