Tuesday, September 27, 2011

Below I'm going to address a bug that exists from Exchange 2007 RTM to Exchange 2010 SP1 (as of this writing). Sometimes when you install Exchange 2010 in a new environment your routing group connector does not get created - colleagues of mine have seen this before.

This happens even when when you specify an Exchange 2003 server in the dialog box below during the Exchange 2010 setup wizard.

When it doesn't get created during the installation if you dig down through your system logs in event viewer you will notice event 1002 from the MSExchangeSetup. See below, pay attention to the bold text.

The New-RoutingGroupConnector command will only connect to SMTP Virtual Servers that have a common name value of 1. What do I mean by this? In the Exchange 2010 source code the Exchange 2010 product team coded this powershell command to query:

What is this object? This is your SMTP virtual server your administrators see in Exchange 2003 system manager. Any configuration changes made to this virtual server get updated on this Active Directory object in the configuration partition.

If an administrator creates new SMTP virutal servers then deletes the first SMTP virtual server that had a CN value of 1 the issue occurs. For example if I open ADSIEdit in my environment with the problem and navigate to the following location:

2. Force replication to whichever DC your Exchange 2003 server is communicating to. You can find this out by running "nltest /dsgetdc:domain.local" on your Exchange 2003 server provided you have the 2003 support tools installed.

Note: If you manually try and use the New-RoutingGroupConnector in Exchange 2007/2010 shell after the installation is complete, it will also unless you correct the CN= value for your SMTP Virtual Server.

Today I set out to perform a single Exchange 2003 server migration to a new Exchange 2010 server for approximately 200 users. What is a simple task for me had some bumps.

I installed setup my new Exchange 2010 server as a brick level deployment "all roles on one server".

I performed the following steps:1. Installed the Exchange 2010 SP1 prerequisites for MBX, HT and CAS.2. Installed the Microsoft Office 2010 filter packs3. Performed the Schema update using setup.com /PrepareAD4. Installed Exchange 2010 with all roles.

After installation completed successfully I rebooted the server. After the reboot I noticed I could not connect to Exchange 2010 using the console or shell. I checked to see if the powershell virutal directory existed... it did not.

For some reason only the mailbox role installed, even though the wizard said all roles were installed successfully. I went back and ran setup.exe again. I selected Hub Transport and Mailbox.. went through the install - rebooted. This time all roles existed. Although Exchange 2010 installed, it was unusable.

When I tried to perform powershell commands in the shell as an Exchange organisation administrator I received the following errors:

FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042 is a Exchange 2010 built in arbitration user account which must exist in every Exchange 2010 environment. The GUID never changes, it is always "4c1f4d8b-8179-4148-93bf-00a95fa1e042".

The setup failed because someone deleted this user account from Active Directory!

How can we get it back?

You have two ways to get this mailbox back. If you have a computer on your network with the Exchange 2010 management tools installed, you can create the user account using powershell with the following command:

What happens if you do not have exchange management shell installed on any computers? Well there is another way to get this account back. This account is originally created when you prepare the domain/schema. If you run setup.com /PrepareAD on your domain it will re-create this account for you. See below:

Sunday, September 18, 2011

Windows Server Backup or wbadmin.exe cannot be used to backup passive databases in a Database Availability Group environment.

WSB does not back up Passive copies. It can only be used to back up Active copies. This is simply a limitation of the WSB plug-in. Also WSB is only designed to backup small Exchange 2010 environments that are not DAG members.

Also – as indicated in the article, you have to back up the entire volume containing both the database/logs.

So essentially if you want to use WSB to take a full backup of *all* databases, you are looking at either moving all active copies to a single DAG member (for the backup), or using WSB locally on each DAG member that hosts active databases.

Please note, you can backup passive mailbox databases using WSB in a DAG environment as explained in the above article:

"If a server hosting the data being backed up is a member of a database availability group (DAG) and hosts both active and passive database copies, you must disable the Microsoft Exchange Replication service VSS writer. If the Microsoft Exchange Replication service VSS writer is enabled, the backup operation will fail."

Why would you want to use windows server backup to backup a DAG member? Possibly your primary backup product is failing and you want to test the VSS service using an alternative product? In this case you may use BETest.exe to test the VSS snapshot service.

Domain Rename's are possible only with Exchange 2003. After you perform the Active Directory rename using the domain rename tool RENDOM, the next step is the fixup the Exchange 2003 attributes using a tool called XDR-Fixup.

Wednesday, September 14, 2011

Today I discovered what may be a bug in ADAMSync, however I found a workaround. Let me go into detail sharing my findings with you. First... lets cover off my environment.

I have 4 forests, 10 domains. My AD LDS server is a member of subdomain.forest3.lan. Please see the diagram below.

- My LDS Server has multiple instances "LDS Databases" for each Active Directory domain. These instances are listening on 10001, 10002, 10003, 10004 etc... There is a 1 to 1 relationship between a single domain and its corresponding LDS instance.

- Each LDS Instance has only one application partition with the same distinguishedName mapping an Active Directory domain. For example dc=forest2,dc=lan or dc=bu2,dc=forest1,dc=lan.

- There is no synchronization errors. I have validated all attributes declared in my adamsync.xml file are successfully synchronizing to the corresponding userProxy object in LDS for each user account.

- ADAMSync is successfully creating the same Organisational Unit structure matching that of LDS.

- The base distinguishedName of each LDS instance matches the base distinguishedName of the Active Directory domain.

- All child domains in forest1 synchronise using an ldapquery account located in the parent forest1.lan domain. This is configured in the XML file ldapquery and forest1.lan.

- forest2.lan synchronises using an account in forest2.lan

- forest3.lan synchronises using an account in subdomain.forest3.lan. No user accounts reside in the root domain forest3.lan. This is configured as an "empty root domain".

- forest4.lan synchronises using an account located in forest4.lan

The following Active Directory accounts were setup to make this solution work:

- subdomain.forest3.lan\LDSSVC. This account is only a member of "domain users" in subdomain.forest3.lan. This account has "Log on as service" rights assigned under "user rights assignments" on the LDS Server. This account provides the security context under which LDS Instance runs as a service. i.e. all LDS Services run as this account.

- subdomain.forest3.lan\LDSBoss. This account is only a member of "domain users" in subdomain.forest3.lan. During the installation of each LDS Instance using the "Active Directory Lightweight Directory Services Setup Wizard" this account was specified as the Administrator of each instance. This account has no access to the LDS Server itself, i.e. the account does not even have permissions to login to the LDS Server. It only has "Administrative privilages" inside each LDS Instance. All commands which manipulate LDAP data inside an LDS Instance such as ADAMSync must be run under the security context of this LDSBoss account.

- forest1.lan\ldapquery. This account is a member of "Domain Admins" and "Enterprise Admins"in the forest1.lan root domain. It is specified in the ADAMSync.xml file for each child domain in the forest1.lan forest. This account is used to perform LDAP Queries against the forest1.lan forest. If this account is not a Domain Admin or Enterprise Admin, ADAMSync fails to run.

- forest2.lan\ldapquery. This account is a member of "Domain Admins" in the forest2.lan domain. This is specified in the ADAMSync.xml file for the forest2.lan forest. It is used for LDAP queries against forest2.lan

- subdomain.forest3.lan\ldapquery. This account is a member of "Domain Admins" in the subdomain.forest3.lan domain. This is specified in the ADAMSync.xml file for the subdomain.forest3.lan forest. It is used for LDAP queries against subdomain.forest3.lan

- forest4.lan\ldapquery. This account is a member of "Domain Admins" in the forest4.lan domain. This is specified in the ADAMSync.xml file for the forest4.lan forest. It is used for LDAP queries against forest4.lan

So whats the bug you found clint?

I went and installed my ADAMSync XML configuration file running a command prompt under the security context of the user account SUBDOMAIN\LDSBoss with the following command:

When prompted I entered the password for the subdomain.forest3.lan\ldapquery account which was specified in the ADAMSync XML file.

When I run ADAMSync.exe using my SUBDOMAIN\LDSBoss credentials (the credentials used to install the XML configuration file), the sync works successfully.

However I then created another account called SUBDOMAIN\boessenc_admin which I added to the configuration partition "Administrators" group in my LDS Instance. When I tried to sync using my SUBDOMAIN\boessenc_admin account the sync failed with ADAMSync.exe terminating. The following error is received:

I submitted this memory dump to James Li from the Microsoft Directory Service Support Team. James analysed the memory dump carefully and suspects it might be caused by a bug in AdamSync.exe. Here is the stack information he provided me with:

I continued investigating the issue... I then reinstalled the ADAMSync XML file by re-running the ADAMSync.exe process under SUBDOMAIN\boessenc_admin using the same command, and specifying the password for the SUBDOMAIN\ldapquery which was specified in the XML configuration file:

I then ran the ADAMSync.exe program with the sync switch under the security context of SUBDOMAIN\boessenc_admin. It worked!

What did we learn?

Whatever account you used to install the ADAMSync.exe XML configuration file, i.e. the account the ADAMSync.exe process is running as during the config installation MUST also be used to perform the ADAMSync.exe synchronisation. If you attempt to perform a synchronisation using a different account other then the account used during the XML import, the ADAMSync.exe process will crash.

In this post I will give you some information around publishing Exchange 2010 with Forefront Threat Management Gateway (TMG) or ISA 2006 and weather or not these servers should have domain membership.

Microsoft's recommended deployment is that you add your TMG servers as members of your Active Directory domain. For the TMG setup whitepaper please see the following link. This whitepaper explains how to setup TMG step by step with domain membership.

When Microsoft initially released Threat Management Gateway, it did not support workgroup configuration. It's a product that is designed to run as a member of your Active Directory domain and configuring it any other way results in significant loss in functionality and in some cases security. I managed to find a copy of the original release notes published by Microsoft which is available here... stating that TMG does not support workgroup configuration. http://technet.microsoft.com/en-us/library/cc487898.aspx

Previous versions of the product such as ISA2006 did support workgroup configuration and some companies implemented it in this method. There was an outcry and as a result Microsoft changed their stance on this and updated the product to support domain membership.

Can you publish Exchange 2010 using TMG without adding the Threat Management Gateway server as a member of your internal Active Directory domain? Yes you can, there are 3 ways to do this:

- Configure an internal PKI, if you want security you need to ensure you have an offline root stand-alone CA, and a subordinate enterprise issuing CA which is AD Integrated. Issue a digital certificate to each domain controller and configure your environment to support LDAP over SSL for AD Authentication. To configure your domain controllers to support LDAPS using SSL see http://support.microsoft.com/kb/321051

- Will require additional servers weather its certificate authorities, radius servers or domain controllers to run a new AD forest.

- Will extend the project life cycle from an originally estimated 2 weeks to 4-8 weeks depending which of the 3 options you wish to go down.

- Increase complexity of your network and increase downtime periods should infrastructure fail as this is not a highly available deployment.

Neither of these solutions add any significant layer of security and are not seen as efficient solutions due to the Administrative overhead they create.

In a Microsoft whitepaper written by Greg Taylor "Publishing Outlook Anywhere Using NTLM Authentication With Forefront TMG or Forefront UAG", Greg dedicated a section around joining Forefront TMG/Forefront UAG to an Active Directory domain or leaving it workgroup. For a copy of this article see the following URL:

"Domain Joining Forefront TMG/Forefront UAG or Leaving in a Workgroup"

In most organizations, the decision whether to domain join the server hosting Forefront TMG/Forefront UAG to your production domain may be one of the more contentious parts of the deployment.

For Forefront UAG deployments, the guidance is clear. Because Forefront UAG is not a firewall, it should be placed behind some other device that acts as a firewall on the corporate network. Also, it's recommended that Forefront UAG be domain joined to make authentication simple and flexible. Forefront TMG is installed on the Forefront UAG computer during installation, but that's done only to protect the host system and for the underlying functionality it provides to Forefront UAG.

Forefront TMG deployments are more complex to discuss because Forefront TMG is considered a firewall and can protect the network edge. Domain joining Forefront TMG offers many advantages: it allows certificate based authentication to be used at Forefront TMG, using Kerberos Constrained Delegation to communicate to Exchange; it allows easy use of Active Directory groups and user objects in publishing rules to restrict access; and it provides other benefits. For an impartial view on whether to domain join Forefront TMG, see Debunking the Myth that the ISA Firewall Should Not be a Domain Member. For more information about identifying your infrastructure design requirements, see Domain and workgroup requirements.

The link Greg Taylor mentions in his white paper "Debunking the Myth that the ISA Firewall Should Not be a Domain Member" by Thomas W Shinder, Microsoft MVP is an excellent read. Please view it here:

ISA/TMG that is a domain member machine is more secure and more flexible than a non-domain member machine and that they do themselves and their companies a disservice by not joining the ISA firewall to the domain. This is a significant issue and not something to be taken lightly because there is a serious security hit you take when you don’t join the ISA firewall to the domain.

He also covers in his article the primary reason companies go through all this effort of not joining the TMG/ISA server to the internal domain, compliance managers and external auditors that believe in this myth. He writes:

Should the ISA firewall array be placed in a domain or a workgroup? That is the question. Is it nobler to place the ISA firewall in a workgroup where you can avoid the catcalls of clueless compliance managers, "hardware" firewall know-nothings, or “network guys” who think of network security as "port opening and closing", or should you bear the slings and arrows of the same harridan housewives and carping screws for placing the ISA firewall in the domain, where you can get a higher level of overall security and substantially improve your security position?

The last article I would like to point you at is a TechNet article published by Microsoft around considerations when and when not you would place your TMG server as a member of your internal Active Directory domain. Please view this article here:

I would like to finalise by saying majority of TMG deployments should all be a member of your Active Directory domain especially if your just publishing Exchange 2010. However there may be circumstances where your using your TMG server for things other then just Exchange and you may need to look at implementing TMG in a workgroup configuration.

Joining Forefront Threat Management Gateway 2010 to an Active Directory domain to publish Exchange 2010 services to the Internet is not a security threat to your network.

Sunday, September 4, 2011

Scenario: I have an administrators XP workstation. The administrator has a standard user account and an administrator account. I migrated his standard user account and administrator account to a new Active Directory forest. ADMT performed security translation on his profile. The administrator can successfully login to the new domain keeping his same profile and settings.

Problem: The administrator opens MMC using "run as" and specifies his administrative credentials in the source forest. He can access AD Users and Computers and make configuration changes. When he tries to add group policy management console (GPMC) to the MMC console he receives Access is Denied.

I used Sysinternals Process Monitor (Procmon.exe) and noticed it was having problems writing to a particular registry key.

I granted the administrator account full control over the profile using regedit.