Prepare Active Directory for Exchange 2007

To prepare active directory for Exchange 2007 you need to perform the following actions:

On the Schema master using an account with appropriate privileges navigate to the root of the installation media and run the following from the command prompt:

setup /pl

The command above prepares the legacy permissions. Next run:

setup /ps

This prepares the AD Schema. Next run the following command, where ORGANIZATION_NAME is the name of your Exchange Organization:

setup /PrepareAD /organizationName:ORGANIZATION_NAME

This creates the necessary OUs and security groups for Exchange. Then run:

setup /pd

This prepares the local domain for Exchange.

References:

http://technet.microsoft.com/en-us/library/bb125224(v=exchg.80).aspx

Advertisements

NtFrs Event ID 13555 and 13552 The file replication Service is in an error state

I discovered an issue at a client site the other day where event IDs 13555 and 13552 with a source of NtFrs were present in the event log of a Windows Server 2003 Domain Controller. The relevant error messages were as follows:

‘The File Replication Service is in an error state. Files will not replicate to or from one or all of the replica sets on this computer until the following recovery steps are performed’

The File Replication Service is unable to add this computer to the following replica set:

“DOMAIN SYSTEM VOLUME (SYSVOL SHARE)”

In this case the network had a single DC. It appeared from the errors that the SYSVOL share was in an inconsistent state. This error had obviously first occurred some time before and as a result there were no system state backups from when the SYSVOL share was in a consistent state.

To fix the error I had to set the Burflags option to D4 under the following registry key to force the DC into thinking an authoritative restore had been performed:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica Sets\GUID_OF_YOUR_REPLICA_SET\Burflags

After Setting this, and restarting the server the errors disappeared.

In a multi Domain Controller network much more care needs to be taken. On the plus side in this case you will normally have a good copy of SYSVOL on a different DC. Detailed information on how to recover from this error in a multi Domain Controller network can be found in the references below but the basic premise is this:

  • Stop NtFrs on all servers
  • Set Burflags to D4 in the registry of a Domain Controller with a known good copy of SYSVOL and start NtFrs
  • Set Burflags to D2 on the remaining Domain Controllers and start NtFrs

Exercise extreme caution if using the advice above. It is not a substitute for restoring from a good system state backup if you have one, and more of a last resort. In any event refer to the Microsoft documentation for much more detailed instructions.

References:

How to rebuild the SYSVOL tree and its content in a domain

Burflags Query

Using DNSlint to verify the integrity of DNS records used for Active Directory Replication

DNSlint is a Microsoft Support tool that can be used to inspect the integrity of your domain’s DNS records. This can be useful if you are having problems with Active Directory replication, or if you want to check the integrity of your of your DNS records after removing a failed Domain Controller for example.

To check DNS records used for for AD replication in your domain install DNSlint and run the following command:

dnslint /ad /s IP_ADDRESS

Where IP_ADDRESS is the IP address of one of the DNS servers in your domain.

References:

DNSlint Utility

 

Find an active directory users organizational unit (OU) using Powershell

Have you ever forgotten which organizational unit an active directory user resides in? You can use ‘Active Directory Users and Computers’ to quickly find the user using the ‘Find’ function but this doesn’t easily tell you which OU they belong to. Here is a very quick command to find the organizational unit (OU) that a user belongs to using Powersell, where USERNAME is the username  of the user you wish to examine. Simply run the Powershell, and then enter:

Get-ADUser USERNAME

This will return the users details, including the Distinguished Name of their account, which will show which OU they belong to.

Using Get-ADUser to obtain OU information

If you don’t know their username, you can use the filter option to search by firstname or surname. Here is an example filtering by surname where USER_SURNAME is the users surname:

Get-ADUser -filter {Surname -like “USER_SURNAME“}

Restrict or filter GAL access for OWA users using MSExchQueryBaseDN in Exchange 2007

When hosting Exchange 2007 mailboxes for use purely with Outlook Web Access (OWA) you may wish to limit access to the Global Address List (GAL), so that logged in users can only see a subset of the contacts in the GAL. This would be particularly relevant in hosting environments where mailboxes may be hosted for multiple companies in the same active directory, and you might want users to only see contact information from users for their company, rather than all companies.

A while ago we had a situation where this was a requirement. In our case there were several groups of users who would only be accessing email through OWA, and only needed contact information for a subset of staff. We were able to use custom address lists and the MSExchQueryBaseDN user attribute to solve this problem.

If you run adsiedit.msc and look at the properties of a user object you can scroll down the list of attributes to find MSExchQueryBaseDN.

The MSExchQueryBaseDn attribute in adsiedit

In order to limit which contacts a particular user or group of users can access, firstly you need to set up a new Address List either using the Exchange Management Console, or Exchange Management Shell. The address list should contain the contacts that you want the user or group of users to be able to view. Please note that you could point the MSExchQueryBaseDN attribute to an Organizational Unit, so it would filter contact information for just the users in that OU, but if you need the flexibilty to include contact information for users from various OUs in active directory, it may be easier to use a custom address list.

Once this is done you need to set the MSExchQueryBaseDN attribute of each of the users who you want to restrict to the distinguished name of the address list you created.

e.g.

CN=YOUR_RESTRICTED_ADDRESS_LIST,CN=All Address Lists,CN=Address Lists Container,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=YOUR_DOMAIN,DC=local

Where YOUR_RESTRICTED_ADDRESS_LIST is the name of your address list and YOUR_DOMAIN is the name of your domain.

Obviously it would be too time consuming to set this attribute manually for hundreds of users so you could either use ADModify if you want to use a GUI:

Set MSExchQueryBaseDN using ADModify.Net

To reset to the default value using ADModify.Net use a value of ‘null’.

You could also use  to achieve this in Powershell if you would prefer to use the command line. Further details can be found here.

Please note: Using this attribute in Exchange 2010 SP1 may result in undesirable consequences. It has been reported that if this attribute is used you may find that users with the attribute set cannot view the contents of their address list, particularly in Outlook.

Export a list of members from an Active Directory group to a text file

I needed to export a list of all the members in an active directory group today. Here are two methods which work well. The first example uses the net group command. In both examples ‘Group Name’ is the name of the group that you want to export the member list for, and memberlist.txt is the name of the output file.

net group “Group Name” /domain > memberlist.txt

The second example uses dsquery and dsget, which will return the full distinguished names of the user objects that are members of the group. This could be useful if you also need to know which organizational unit the members accounts reside in.

dsquery group -name “Group Name” | dsget group -members > memberlist.txt

Force KCC (Knowledge Consistency Checker) to run on a domain controller

Sometimes after demoting domain controllers you may be left with inconsistent NTDS connection objects in Active directory. In my case there was an NTDS connection object listed under one of the domain controllers at our central site which referenced a recently demoted domain controller at a remote site. I needed an NTDS connection object pointing pointing to the newly installed DC at the remote site instead. To fix this i simply deleted the incorrect NTDS connection object in the ‘Sites and Services’ console, from the central site domain controller, and then forced KCC to run on the same domain controller by running:

repadmin /kcc

This forces the domain controller that you run the command on to check its inbound replication topology immediately and generate any missing connections. After running this command a new NTDS connection object was generated from the new DC at the remote site. This can either be verified by checking under the Domain Controllers NTDS Settings, in the ‘Sites and Services’ Console or by running:

repadmin /showrepl