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

Create a bootable WinPE boot disk to capture images using imagex

Here is a quick list of commands to create a basic WinPE bootable ISO image to use for capturing images of computers using imagex. First of all make sue that you have downloaded and installed the Windows AIK (Automated Installation Kit) on your computer which can be found here. Once the Windows AIK is installed run the ‘Deployment Tools Command Prompt’ form the Start Menu under ‘Microsoft Windows AIK’. In the ‘Deployment Tools Command Prompt’ run the following command which will create a folder on your C:\ drive called ‘winpe-bootdisk’ with all the necessary files to create the bootdisk:

copype.cmd x86 c:\winpe-bootdisk

The copy the winpe.wim base image to the c:\winpe-bootdisk\ISO\sources folder, renaming it to boot.wim

copy c:\winpe-bootdisk\winpe.wim c:\winpe-bootdisk\ISO\sources\boot.wim

Next you can mount the boot.wim image file to add any other tools that you want to include on the bootdisk. Once mounted the file system for boot.wim file can be found under c:\winpe-bootdisk\mount:

Dism /Mount-Wim /WimFile:C:\winpe-bootdisk\ISO\sources\boot.wim /index:1 /MountDir:C:\winpe-bootdisk\mount

If necessary copy any other tools you want to the boot.wim image e.g. imagex:

copy “C:\program files\Windows AIK\Tools\x86\imagex.exe” C:\winpe-bootdisk\mount\Windows\System32

You may also want to add additional packages or tools e.g. WSH (Windows Scripting Host) support

Dism /image:C:\winpe-bootdisk\mount /Add-Package /PackagePath:”C:\Program Files\Windows AIK\Tools\PETools\x86\WinPE_FPs\en-us\winpe-scripting.cab”

When you have finished adding stuff to the wim image unmount the boot.wim image and commit ther changes using the following command:

Dism /unmount-Wim /MountDir:C:\winpe-bootdisk\mount /Commit

Finally use oscdimg to create the boot disk ISO image

Oscdimg -n -bC:\winpe-bootdisk\Etfsboot.com C:\winpe-bootdisk\ISO C:\winpe-bootdisk\winpe-bootdisk.iso

After this you can burn the image to CD, and start using it! To capture an image of a computer using your new WinPE boot disk run the following command, where DRIVE_TO_CAPTURE is the name of the drive you want to cature and DESTINATION_FILE is the location and name of the wim file that you want to save the image to:

imagex /capture DRIVE_TO_CAPTURE DESTINTATION_FILE /compress fast verify

e.g.

imagex /capture E: D:\win7-corp.img /compress fast verify

References:

http://technet.microsoft.com/en-us/library/dd744533(WS.10).aspx

http://technet.microsoft.com/en-us/library/dd799303(v=ws.10).aspx

iSCSI shares disappear after reboot on Windows

I experienced a problem the other day on one of our Windows 2003 servers where shares created on an iSCSI LUN connected to the server disappeared after the server was rebooted. By this I mean that folders that had previously been shared on this device were no longer shared, and needed to be completely reconfigured.

I turns out that this is due to the fact that the ‘iSCSI initiator’ service has not initialised by the time that the ‘Server’ service has started, and so the drive is not yet available, and therefore the shares are not recreated on boot up. A quick google lead me to a Microsoft KB article which outlines how to configure the ‘Server’ service to depend on the ‘iSCSI Initiator’ service allowing the drive to initialise before the ‘Server’ service has started. Simply follow the KB to fix the issue.

References:

File shares on iSCSI devices may not be re-created when you restart the computer

Deploying Java and Adobe Reader via Group Policy

Java:

Firstly download the latest Java Windows offline installer here.

Run the installer, and wait for the Welcome screen to appear. Next, navigate to the following directory, where USER_NAME is the name of the logged on user, and jre_VERSION is the name of the version of Java that you have just extracted:

C:\Users\USER_NAME\AppData\LocalLow\Sun\Java\jre_VERSION

In this folder you will find an msi file and a data.cab file. Copy the jre_VERSION folder to you network deployment point, and then add the msi file path to a new package in the software installation section of the Group Policy Object (GPO) that you wish to deploy Java to.

 

Adobe Reader:

Simple Method:

Download the most recent MSI file from ftp://ftp.adobe.com/pub/adobe/reader/win and deploy that to a new package in the software installation section of the GPO that you wish to deploy to e.g. AdbeRdr11000_en_US.msi. Note that Adobe only issue MSI files for the major releases e.g. 11.0.00.

Complex Method

This method includes how to patch the MSI file of the major release outlined in the simple method to include all the latest security patches. Firstly download the MSI file for the major release which you want to patch and place it in a folder on your computer e.g. C:\ADOBEREADER

Next download the .exe file for the update version which you want to patch to e.g. 11.0.01 from ftp://ftp.adobe.com/pub/adobe/reader/win and extract the contents using the following command, where _VERSION is the version number of the file you downloaded:

AdbeRdr_VERSION_en_US.exe -nos_ne

e.g. AdbeRdr1101_en_US.exe -nos_ne

This will extract the contents of the .exe file to a subfolder in the C:\ProgramData\Adobe\Setup folder. Copy the .MSP file contained in this folder to the C:\ADOBEREADER folder you created earlier. From the command prompt navigate to the C:\ADOBEREADER folder and run the following command where MSI_VERSION is the version of the MSI file that you are updating and PATCH_VERSION is the version of the patch that you are applying :

msiexec /a AdbeRdr_MSI_VERSION_en_US.msi /p AdbeRdr_PATCH_VERSION.msp

e.g. msiexec /a AdbeRdr11000_en_US.msi /p AdbeUpd11001.msp

Click through the steps of the installer, and then click finish. Your .msi file has now been patched

Finally, copy your new patched msi file to your network deployment point and create a new package in the software installation section of the GPO which you wish to deploy Adobe Reader to.

References:

How do I deploy Java using Active Directory across a network?

How to extract an MSI file from the EXE for Adobe Reader

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

 

Windows Server 2008 R2 SP1 install breaks RDP

After installing Service Pack 1 via windows update on a Windows Server 2008 R2 machine the other day, I discovered that I could no longer use remote desktop connection to access the server remotely. At first I wasn’t sure if the whole service pack installation was botched, but further testing revealed that all other functions of this server were operating normally. A quick google search showed that I was not alone in experiencing this problem, in fact there is enough information out there to solve this without another blog post from yours truly, but there is a bit of conflicting information so I thought I would document my experience to hopefully help others.

The problem manifests itself like this:

You try to RDP the affected server and it goes through the enitre logon process, and just when you think it is going to fire up the remote desktop it bombs out. An event was logged in the application log in my case event 4005 with a source of Winlogon, stating ‘The Windows logon process has terminated unexpectedly’ (shown below), although I have read of slightly different errors on other blog posts. Checking the Terminal Services logs indicate that the logon has completed successfully.

Event 4005 Source Winlogon after Service Pack 1 install on Windows Server 2008 R2

This situation it turns out, occurs when both KB2621440 and KB2667402 are applied to a system before Service Pack 1 is applied, as they effectively leave some of the RDP DLL files out of sync, specifically rdpcorekmts.dll. Now, alot of the posts I read online stated that you simply needed to uninstall the KB2777402 update, reboot, and then reapply it to solve this problem. I tried this first and it did not work. Various posts also stated that RDP started working after the removal of this patch, again this was not the case for me although I am sure it is correct in some cases.

So the fix I used in the end was this:

Firstly I uninstalled both KB2621440 and KB2667402 via Control Panel, Uninstall a Program, View Installed Updates, and then rebooted the server. I expected the DLLs to be set back to a working state at this point but this was not the case. Luckily in my case I had physical access to the server. Other posts state that the two updates can be uninstalled remotely using the following commands if you do not have that luxury:

wmic /node:<SERVER> /user:<USER> process call create “powershell wusa /uninstall /kb:2667402 /quiet /forcerestart”

wmic /node:<SERVER> /user:<USER> process call create “powershell wusa /uninstall /kb:2621440 /quiet /forcerestart”

Note, that the commands above will restart the server

As RDP still didn’t work for me at this point contrary to other information, I ran:

sfc /scannow

This picked up some issues and required a reboot. After rebooting the server I was able to use RDP again. That was great, but didn’t help with the fact that the two patches that were removed were to address the Critical RDP vulnerability MS12-020. I certainly didn’t fancy not applying these patches to this server so I reapplied KB2621440 and KB2667402 via Windows Update, and rebooted the server. Thankfully after this I had a fully patched server and working RDP.

If you need to do all of this remotely and find that you still can’t RDP the server after removing the two patches using the commands above I recommend running sfc /scannow using PSEXEC:

psexec \\SERVER sfc /scannow

Then when the scan is finished performing a remote reboot using:

psexec \\SERVER shutdown -r -t 01

This should get your RDP back to a working state, and then you can reapply the removed updates. I have not corfirmed this but expect this fix will also work for Windows 7.