Alexander’s Blog

If you try to install Exchange Server 2010 Service Pack 1 (SP1) on a server in the environment where the NetBIOS domain name of a domain controller contains an ampersand (&) character, the server installation will fail and you are likely to see the following error.

An error occurred while parsing EntityName. Line7, position 12.

This issue occurs because the “&” character is a reserved character in XML. Therefore, the character causes the parsing for current logon user to fail. Here’s how you can solve the problem. The solution used to be documented in KB article 2491951 but recently when I tried to find the article on the Internet I was unsuccessful. Luckily, I have documented the solution for you in the following steps.

1. Copy all the installation files from the CD to a hard disk, and then open the ManageScheduledTask.ps1 file in the scripts folder.
2. Locate the following lines.
   function Get-CurrentUserName
   {
   [System.Security.Principal.WindowsIdentity]$id = [System.Security.Principal.WindowsIdentity]::GetCurrent()
   $id.Name
   }
3. Change the lines as below.
   function Get-CurrentUserName
   {
   [System.Security.Principal.WindowsIdentity]$id = [System.Security.Principal.WindowsIdentity]::GetCurrent()
   [System.String]$fixedName = $id.Name.Replace(‘&’,'`&’)
   return $fixedName
   }
4. Save the file, and then try to install Exchange Server 2010 SP1 from the hard disk.
5. Install Update Rollup 4 for Exchange Server 2010 Service Pack 1.

We all know that it is fairly easy to host servers in virtual environments these days. In fact, it is so easy that people can often overlook the implications of hosting Active Directory Domain Controllers (DCs) in a virtual environment. Because Active Directory doesn’t support any method that restores snapshots of the operating system due to the fact that it can cause an Update Sequence Number (USN) rollback, one can argue that Domain Controllers are not really supported in a virtual environment.

Although I wouldn’t go as far as stating that DCs are not supported in a virtualized environment but clearly snapshots are not supported for virtualized DCs because of the way Active Directory was designed. If you decide to run DCs in a virtualized environment, here are some solutions that are documented in Microsoft’s KB article 888794. This is only a partial list. For the complete listing check out the KB article.

If the virtual hosting environment software correctly supports a SCSI emulation mode that supports forced unit access (FUA), un-buffered writes that Active Directory performs in this environment are passed to the host operating system. If forced unit access is not supported, you must disable the write cache on all volumes of the guest operating system that host the Active Directory database, the logs, and the checkpoint file.

Make sure that all the domain controllers perform inbound replication on all locally held Active Directory partitions according to the schedule defined on site links and connection objects, especially in the number of days that is specified by the tombstone lifetime attribute.

When a domain controller runs in a virtual hosting environment, do not pause the domain controller for long periods of time before you resume the operating system image. If you do pause the domain controller for a long time, replication may stop and cause lingering objects.

An Active Directory domain controller requires regular system state backups to recover from user, hardware, software, or environmental problems. The default useful life of a system state backup is 60 or 180 days, depending on the operating system version and the service pack revision at play during the installation. This useful life is controlled by the tombstone lifetime attribute in Active Directory. At least one domain controller in every domain in the forest should be backed up every tombstone lifetime number of days. In a production environment, you should make system state backups from two different DCs on a daily basis.

In an effort to boot with the latest zone contents, the Microsoft DNS Server service waits 15 or more minutes for Active Directory to inbound replicate before loading an AD-integrated DNS zone. Configuring DC guests to point to themselves as primary for name resolution causes domain controllers to hang while applying network connections during OS startup. Virtualized domain controllers should point to one or two reliable off-box DNS Servers to insure faster OS startup. Similarly, virtual host computers should point to one or two off-box DNS Servers for name resolution. Virtual host computers should not point to virtualized DNS Server running on the local virtual host computer.

To roll back the contents of Active Directory to a previous point in time, restore a valid system state backup. A system state backup can be restored up to the tombstone lifetime number of days after the backup was performed. The backup must have also been made on the same operating system installation as the operating system that you are restoring. Active Directory does not support other methods to roll back the contents of Active Directory. In particular, Active Directory does not support any method that restores a “snapshot” of the operating system or the disk volume the operating system resides on. This kind of method causes a rollback in the update sequence number (USN) used to track changes in Active Directory. When a USN rollback occurs, the contents of the Active Directory databases on the improperly restored domain controller and its replication partners may be permanently inconsistent.

If you are running servers, or plan to run servers, in a virtual environment it is good for you to know the support policy documented by Microsoft in the KB article 897615: Support policy for Microsoft software running in non-Microsoft hardware virtualization software.

The Microsoft Online Services Directory Synchronization tool provides one-way synchronization from your local Active Directory directory service to Microsoft Online Services. Directory synchronization can also provide global address list synchronization between your local Microsoft Exchange Server environment and Microsoft Exchange Online.

Here’s a video from Microsoft on how to install and configure the Directory Synchronization (DirSync) Tool.

WMV version

Web browser version

To learn more about Microsoft Online Services Directory Synchronization tool, click here.

Here’s a trivia for you.

Did you know that the first name, last name, display name, full name, logon name, and SAM account name can all be different for a single user account in Active Directory?

There are some things in software products that are implemented in such a bizarre way that I can’t resist blogging about them. One such example is the Full Name attribute in Active Directory accounts. The way Microsoft implements Full Name is rather interesting. Do not confuse Full Name with Display Name. They are two completely different attributes. By default, the Display Name is a combination of a user’s first and last name. Unlike Display Name, the Full Name attribute is not visible in the GUI and cannot be set within the properties of the user account.

Try this. Look at all the properties of a user account closely. You won’t find Full Name anywhere. You will find Display Name, which is not the name that is displayed in Active Directory Users and Computers. So what is the actual Display Name that is displayed in Active Directory Users and Computers? Well, the actual name that is displayed is the Full Name. I am not kidding. The next obvious question you are going to ask is how do I change the Full Name if it’s not shown in the GUI? Answer: By right-clicking the account and selecting Rename you will notice a pop-up Window that will show you the Full Name.

So let’s summarize what we’ve learned so far. The Full Name is by default a combination of a user’s first and last name but it can be a combination of anything you want, totally unrelated to the actual first or last name. The first name, last name, display name and the full name can be completely independent of each other. You can literally have a first name John, last name Smith, display name David Jones, and a full name Joe Shmoe, as shown in the screenshot below. Play around with these attributes and you will see what I mean.

By the way, the logon name of the user and the SAM account name (Pre-Windows 2000 name) can also be completely independent. So Joe Shmoe, a.k.a John Smith, a.k.a. David Jones can have a logon name of Tony and a SAM account name of Williams. The logon and Pre-Windows 2000 names are configured on the Account tab of the user account properties. Obviously, I am not recommending you configure the account in such a manner, I am just pointing out the fact that first name, last name, display name, full name, logon name, and SAM account name can all be different for a single user account in Active Directory. Which is all fine and dandy, but the way the Full Name and the Display Name is implemented in Active Directory appears rather strange to me. What do you think?

Known Issues

I should point out that the fact that changing the first and last name doesn’t change the Full Name is known to cause developers some headaches (e.g. issues with sharing of a BCM database). The inconsistency in the way this “feature” is implemented has also some known issues with Exchange 2007, as pointed out in this MSDN article.

In the June issue of TechNet Magazine, there is a discussion of how ADFS promises to increase cloud security. here’s a snippet from the article by Jeffrey Schwartz.

“Microsoft’s Active Directory Federation Services (AD FS) 2.0 promises to simplify secure authentication to multiple systems. It will also do the same for the cloud-based Microsoft portfolio. In addition, the extended interoperability of AD FS 2.0 is expected to offer the same secure authentication to other cloud providers, who already support standard protocols, such as Amazon.com Inc., Google Inc. and Salesforce.com Inc.

AD FS 2.0, formerly known as “Geneva Server,” was released in May. This is the long-awaited extension to Microsoft Active Directory that provides interoperable claims-based federated identity management. By adding AD FS 2.0 to an existing AD deployment, IT can allow individuals to log in once to Active Directory and then use their credentials to sign into any other claims-aware systems or applications.”

You can read the rest of the article here.