If you use VMware in virtually any of its flavors, then you've probably become familiar with the list of files created in each folder you create for a virtual machine. Those files are used by the software to process the running of each virtual machine.

But what exactly is each file for? What does each do? Let's take a few minutes to look at the files, and specifically the file extensions, that you'll see within each virtual machine's folder to help you understand the role of each:

.VMDK -- These files are the actual hard disk of the virtual machine itself, and tend to be the largest file within the folder. You can consider the size of this file to be roughly equivalent to the size of either the disk itself (if you've chosen to use preallocated disks) or the size of the data currently stored on that disk (if you use growable disks).

.NVRAM -- Consider this file the BIOS of the virtual machine.

.VMX -- With typically one VMX file per folder, this file holds the configuration information for the virtual machine in a text format. Unlike almost all the other files you'll see, these files can be edited using any text editing program, a process that is actually required for some functionality that is not exposed in the GUI.

.VMXF -- This file, in XML format, includes additional information about the virtual machine if it has been added to a team. If a machine has been added to a team and then later removed, this file remains resident. This file can also be opened and read in a text editor.

.VMTM -- For virtual machines actively participating in a team, this file stores information about that team membership.

.VMEM -- These files, which contain a backup of the VMs paging file, are typically very small or non-existent when the virtual machine is powered off, but grow immediately to the size of configured RAM when the machine is powered on.

.VMSN and .VMSD -- When snapshots are created for a virtual machine, these files are created to host the state of the virtual machine. The VMSN file stores the running state of the machine, what you could consider the "delta" between the VMDK at the point of the snapshot and what has been processed up until the present time. The VMSD stores information and metadata about the snapshot itself.

.VMSS -- If you've suspected the state of your machine, this file contains the suspended state of that machine. These files typically only appear when virtual machines have been suspended.

Depending on the VMware product you use or the platform upon which it resides, these files may be slightly different. However, these files are mostly the same across all versions of VMware's products.

Credit: Greg Shields.

Neither Exchange 2007 nor Exchange 2007 SP1 is supported in production in a virtual environment. However, as stated previously, Microsoft Virtual Server is a good environment for training, labs, and demos. Exchange 2007 and Exchange 2007 SP1 are supported in production environments using only the 64-bit version of Exchange 2007, and currently neither Microsoft Virtual Server nor Microsoft Virtual PC supports 64-bit guest systems. Exchange 2007 and Exchange 2007 SP1 are also not supported in production in a virtual environment using virtualization software that is not Microsoft software. For details about the Microsoft support policy for third-party virtualization software, see Microsoft Knowledge Base article 897615, Support policy for Microsoft software running in non-Microsoft hardware virtualization software.

In addition to the missing Exchange Management Console interface for entering a product key as described in "Evaluations and Product Keys" later in this topic, two other features are not available in the 32-bit version of Exchange 2007:

• Automatic anti-spam updates from Microsoft Update. Only a licensed 64-bit version of Exchange 2007 can get automatic anti-spam updates from Microsoft Update.
• Large numbers of storage groups and databases. You can have a maximum of five databases per server in as many as five storage groups on the 32-bit version.

Microsoft supports Exchange Server 2003 running on hardware virtualization software (virtual machines) only when all the following conditions are true:

• The hardware virtualization operating system is Virtual Server 2005 R2 or a later version.

• The version of Exchange Server that is running on the virtual machine is Microsoft Exchange Server 2003 Service Pack 2 (SP2) or a later version.

• The Microsoft Virtual Server 2005 R2 Virtual Machine Additions are installed on the guest operating system.

• Exchange Server 2003 is configured as a stand-alone server, not as part of a Windows cluster.

• The SCSI driver that is installed on the guest operating system is the Microsoft Virtual Machine PCI SCSI Controller driver.

• The virtual hard disk Undo feature is not enabled.

Reasons to create an SMTP connector include:

• You are connecting to a Microsoft Exchange Server 5.5 computer in another routing group (site), and want to use SMTP.

• You want to configure either server-side or client-side ETRN/TURN.

• You want either to send or not to send ETRN/TURN.

• You want to request ETRN/TURN when sending messages.

• You want to request ETRN/TURN from different servers.

• You want to configure outbound security, and to do it one time and affect many outbound servers.

• You want to permit high, normal, or low message priorities for a domain.

• You want to permit system or non-system messages.

• You want to schedule the SMTP connector.

• You want to use different delivery times for oversize messages.

• You want to queue mail for remote triggered delivery.

• You want to send HELO instead of EHLO.

• You want to specify a specific address space.

• You want to set delivery restrictions.

Controlling the flow of messages from an ISP or Smart Host using
ETRN/TURN. ETRN and TURN are two SMTP commands that control the
flow of messages from an SMTP host to the other end of a part time
connection. For example, consider the case where an SMTP connector is
being used as an organization's conduit for Internet mail messages which are
sent via an Internet Service Provided (ISP). The connector can send its
outgoing messages and then issue the ETRN or TURN command to instruct
the ISP's mail server to reciprocate and send any messages it has in its
queue that are addressed to the organization. The roles are turned ­ first the
organization's SMTP connector is in send mode, then the ETRN or TURN
command is sent and the roles are reversed.

commands should be disabled from the Advanced tab of the connector if they
are not needed. If they are required, keep in mind the distinction between the two
commands. The TURN command requires basic or Integrated Windows security (set
via the Outbound Security button). Both options have shortfalls. Basic security
results in passwords being sent essentially in the clear unless TLS is also utilized and
Integrated Windows security only works in homogenous Windows networks. The
ETRN command does not use any form of password-based authentication. Instead,
it requires the host issuing the ETRN command to provide a fully qualified domain
name to the host that is expected to respond. That host then establishes a new
connection using that fully qualified domain name. This provides a level of protection
that mail is being delivered to the proper mail server, but it is only as reliable as DNS.

Alternately, the SMTP connector can be set up to wait for another SMTP host to
contact it to pick up messages ready for delivery. In this case, the other host issues
the ETRN/TURN command. To set this up to use TURN, one must specify the
account that will be used for authentication. This is accomplished via the Delivery
Option tab.

If ETRN/TURN support is required, the use of TURN with basic authentication plus
TLS is recommended instead of ETRN.

This script takes a CSV file and uses the entries in the columns to create managed folders and a managed folder mailbox policy. It then sets the created policy to all mailboxes.

Usage

Save the script code below into a simple text file and name it ManagedFolderSetup.msh. Open up the Exchange Management Shell and navigate to the directory containing the file you just created. Type:

.\ManagedFolderSetup.msh C:\ManagedFolders.csv

Ensure the path specified for the CSV file is correct.

Sample Script

$newManagedFolders = @()
$existingManagedFolders = @()
$managedFolderLinks = @()

## Name of the managed folder mailbox policy to be created - change this in your script
$managedMailboxPolicy = "General Policy"

if(!($args[0]))
{
write-host "Usage: ManagedFolderSetup.msh ManagedFolders.csv"
return
}

$data= import-csv -path $args[0]

## Create Managed folder
foreach( $i in $data )
{

   $newFolder = Get-ManagedFolder | where {$_.Name -eq $i.Folder}
   if ($newFolder -ne $null) {
        $script:existingManagedFolders += $newFolder
    } else {
        $newFolder = New-ManagedFolder -Name $i.Folder -FolderName $i.FolderName -StorageQuota $i.StorageQuota
        if($newFolder -ne $null) {
              write-host "Done"
              $script:newManagedFolders += $newFolder
         } else {
              write-host "Error: Managed folder" $i.Folder "cannot be created."
            }
      }       
}

write-host "Below Managed folders already exist:"
foreach($i in $existingManagedFolders)
{
write-host $i.Name
$managedFolderLinks += $i.Identity 
}

write-host "Succesfully created below Managed folders:"
foreach($i in $newManagedFolders)
{
write-host $i.Name
$managedFolderLinks += $i.Identity
}

## Create a Managed folder mailbox policy

$newPolicy = New-ManagedFolderMailboxPolicy -Name $managedMailboxPolicy -ManagedFolderLinks $managedFolderLinks
if ($newPolicy -ne $null) {
write-host "Succesfully created below Managed folder mailbox policy:"
$managedMailboxPolicy
} else {
write-host "Error: Managed folder mailbox policy" $managedMailboxPolicy "cannot be created."
return;
}

## Set the created managed folder mailbox policy to all mailboxes
write-host "Set the created policy to all mailboxes:"
$mailboxes = get-mailbox
foreach($mailbox in $mailboxes)
{
$mailbox.Name
Set-Mailbox -identity $mailbox.Identity -ManagedFolderMailboxPolicy $newPolicy.Identity
}

An important piece of info for anyone looking to attach storage to a server in excess of 2TB;

With Windows Server 2003 Service Pack 1 (SP1) and Windows XP 64-bit Edition (x64), these limits have changed.

Microsoft added support for 64-bit block numbers in the disk/class layer, using the new SCSI Commands included in the SCSI-3 Block Commands-2 command set. Microsoft also enabled GPT support for all Windows Server 2003 SP1 platforms. With this change, for example, a snapshot of a GPT partition on an Itanium-based machine can now be transported to a 32-bit machine for data mining or archiving purposes.

The new limits are as follows:

• Basic or dynamic volume size: 2⁶⁴ blocks = 2⁷³ bytes (too big to pronounce)
• Maximum NTFS file system size that can be realized on Windows: 256 TB

Note: Disk devices with more than 2 TB of disk space must be converted to GPT format for all of the disk space to be usable. If the device uses MBR format, the disk space beyond 2 TB will be unusable.

See more at: http://www.microsoft.com/whdc/device/storage/LUN_SP1.mspx#EFB

Introduction

Installing Exchange 2007 is just as easy as previous versions, and once you have prepped AD, the rest is pretty straight-forward. That doesn’t mean you should throw in the CD and start clicking Next! Be sure to review the prerequisites in the first part of this series to reduce any confusion that may lead to errors or worse.

GUI Installation

With all the prerequisites taken care of we can begin the Exchange 2007 installation. The GUI-based installation is pretty straightforward. Insert the CD and run Setup.exe from the root of the disc. You will need certain permissions depending on your current configuration and how you prepared the domain. You will need Enterprise and Local Administrator privileges, and if you have not already prepared the domain you will also need Schema Administrator permissions as well. If you already have an Exchange 2007 server in the domain you will also need to be a member of the Exchange Organization Administrator group.

The Welcome screen will appear and you will see right away if you have the required software prerequisites. Figure 1 shows that the .NET Framework 2.0 is installed (it is grayed out) and MMC 3.0 is also installed but Microsoft Shell (MSH) is missing. If you are missing either of these components, you can simply click on the item to install it.

Figure 1: Prerequisites

Once the install wizard starts you can read over the Introduction then read and accept the EULA. Next you have the option of enabling Error Reporting, make your choice and then click next. You will be given two install choices; Typical and Custom (see Figure 2). The typical install will install all the roles with the exception of the Edge Transport role. If you wish to customize the installation, choose the Custom install option. Here you can also change the install location if you wish to do so.

Figure 2: Install Options

When you choose the custom option and click next you will be given a number of selections and you can choose which role, or roles, to install. You can also select to install Active or Passive Mailbox server clusters, or just install the Management Console (see Figure 3).

Figure 3: Server Roles

Before you can continue, you will have to provide the name of the Exchange Organization and be asked if you have any computers running versions of Outlook 2003 or earlier (see Figure 4). This option will create Public Folders if you select yes, but choosing no will not create any Public folders. 

Figure 4: Outlook Versions

You will need to be aware of a few things when choosing what roles to install where. If you are running a multi-site AD environment you need to install a Hub Transport and Mailbox server in each AD Site. You also must install a Client Access server in each site that contains a Mailbox server. Finally, all the roles can be installed on the same server (except Edge Transport) or on individual servers.

The installation will now run a set of pre-checks to determine if the domain and server are ready to accept an Exchange 2007 server. Figure 5 shows an example of some common errors you will see if IIS is missing, or if the domain is not at the required functional level (notice the Install button is grayed out).

Figure 5: Failed Readiness Check

When all of the Readiness Checks pass, the Install button will appear and you can press it to start the installation (see Figure 6).

Figure 6: Successful Readiness Check

You can watch the install progress and depending on the roles installed it can take a while. Once complete, click Finish and you are ready to begin configuring your Exchange 2007 server (see Figure 7).

Figure 7: Install Progress

CLI and Unattended Installation

Exchange 2007 also supports installation from a command line interface (CLI), which can be used to perform unattended installations as well. There are a number of switches that are required depending on the type of Exchange 2007 installation you are performing.

• /roles – specifies which server roles will be installed. Can be substituted with /r
  • ET or E – Gateway Server
  • HT or H – Bridgehead Server
  • CA or C– Client Access Server
  • MB or M – Mailbox Server
  • UM or U – Unified Messaging
  • MT or T – Admin Tools
• /PrepareAD – is used to prep the Active Directory schema manually. This switch is optional as the schema is extended automatically during installation. Can be substitued with /p
• /TargetDir – specifies the directory in which to install Exchange 2007. Can be substituted with /t
• /SourceDir – specify the location of the install files
• /DomainController – allows you to specify a DC to use. Can be substituted with /dc
• /AnswerFile:filename
• /mode – Determines if the install is a default install or a recovery install. Required if you wish to use the /RecoverServer switch
  • Install – this is the default mode used when no /mode switch is provided
  • Upgrade – this mode is used when upgrading an Exchange 2007 installation
  • Uninstall – this mode is used to uninstall Exchange 2007 or one of its roles
  • RecoverServer – this mode is used when recovering a failed Exchange 2007 server

The basic syntax of a CLI or unattended installation is as follows:

Setup.exe /console /roles:<server roles to install> /mode:<setup mode> [/targetdir:<destination folder>] [/prepareAD] [/RecoverServer] [/?]

To install Exchange 2007 with the Bridgehead, Client Access and Mailbox server roles, you would use the following from a command prompt:

Setup.exe  /roles:ET,MB,CA  or

Setup.exe  /r:E,M,C

Let’s say you wanted to install a Gateway server and put the program files in a directory on the D drive called E2007 and you wanted to read and write from DC1; you would use the following switches with Setup.exe:

Setup.exe  /r:E /targetdir:D:\E2007 /dc:dc1.thelazyadmin.lab

This last example demonstrates what command you would use to install a new Exchange 2007 server during a disaster recovery operation.

Setup.exe  /mode:recoverserver

Once the command is executed, setup will proceed to determine if .NET 2.0 Framework, MMC 3.0 and the Microsoft Shell is installed. If any of the other prerequisite checks fail, setup will stop and display an error message.

Verifying Installation

Once you have completed the installation, you should verify that everything completed successfully. To do this there are a few things you can check out. The first thing you can do is open up MSH and run the following command which will list the roles installed (see Figure 8)

Get-ExchangeServer

Figure 8: MSH Get-ExchangeServer

Next look in the Application Log in Event Viewer for event ID 1003 and 1004 which verify that install was successful. Finally there are a number of log files created that you can browse to verify that the install was successful and if it was not, what might be wrong.

• %SystemDrive%\Exchange\ExchangeSetupLogs\Setup.log – will tell you if the prerequisite checks passed and what roles were installed.
• %SystemDrive%\ExchangeSetupLogs\ExchangeServerMSI.log – will tell you if the file extraction was the cause of any errors.
• %SystemDrive%\ExchangeSetupLogs\Exchange Server Setup Progress.log – will tell you what system changes were made during the installation.
• %SystemDrive%\Program Files\Microsoft\Exchange Server\ Logging\SetupLogs\setup.log – tracks operations during install, look here when an install fails.

Conclusion

There are many possible configuration and installation options in Exchange 2007. The command line interface offers a powerful and scriptable option to deploy Exchange 2007 servers with minimal administrative interaction. Both install options also perform a number of prerequisite checks to ensure your Exchange 2007 installation starts off on the right foot.

http://www.msexchange.org/tutorials/Why-64-Bit-Good-E12.html

http://www.msexchange.org/tutorials/Exchange-12-Monad-based-Exchange-Management-Shell.html

http://go.microsoft.com/fwlink/?LinkId=56642

Installing Exchange has been a pretty straightforward task; however there have been some changes in the install process for Exchange 2007. Part one of this series will cover the prerequisites required and preparation of Active Directory.

Introduction

Installing previous versions of Exchange was never a difficult task as long as you were prepared. You would install the required IIS components then prep the domain and you were ready to go. Exchange 2007 changes the installation procedure, but it is still as easy as previous versions, as long as you understand the differences. 

System-wide Requirements

As with any application, Exchange 2007 has a certain set of requirements that must be met before you can proceed with the installation and these requirements can be spilt into two types, system-wide and server-specific. System-wide requirements ensure that your Active Directory is ready to accept Exchange 2007 servers and server-specific requirements ensure that the server that Exchange 2007 will be installed on can support it.

One of the bigger requirements is that Exchange 2007 requires the domain functional level to be at Windows 2000 native mode or higher (see figure 1). On top of that Exchange 2007 also requires that the Schema master and the Global Catalog servers run Windows Server 2003 with SP1 applied. It goes without saying that you also need a functional DNS infrastructure in place. If you are installing Exchange 2007 into an existing organization, the Exchange mode must be set to native-mode. This means no Exchange 5.5 servers anywhere in the Exchange organization. If you still have any Exchange 5.5 servers, you will need to upgrade them to Exchange 2000/2003 or remove them completely before proceeding with the installation of Exchange 2007.

Figure 1: Domain Functional Levels

As with Exchange 2000 and 2003, the forest and domain needs to be prepared with schema extensions. However, unlike the previous versions, Active Directory does not need to be prepped beforehand, it is done automatically during setup, but the option does exist to allow for manual schema upgrades. During the setup process the server will connect to the Schema Master in an effort to update the schema and this requires that the Schema Master is available and that the account you are running setup with has permissions to modify the schema.

If you wish to prep the domain manually, you can do so with the /PrepareAD switch on any server in the same domain that the Schema Master is in but it is recommended to do this on the Schema Master. Once you have completed this, you will have to wait for the schema updates to replicate throughout the forest before you install any additional Exchange 2007 servers in the organization. 

Finally, as with all Exchange installations, you require certain administrative rights in order to install an Exchange 2007 server. The following is a list of required permissions required to install an Exchange 2007 server into a new, or existing organization.

• Local Administrator on the server
• Enterprise Administrator
• Domain Administrator
• Schema Administrator (only required for first install to extend the Schema)

Server-specific Requirements

Server-specific requirements for Exchange 2007 include both hardware and software. In order to install Exchange 2007 the server must be running Windows Server 2003 x64 and have SP1 installed. You must also install the .NET 2.0 Framework and MMC 3.0 but if you do not have these two components installed, you can install them during setup. 

Exchange 2007’s hardware requirements have been upgraded from Exchange 2003 with the biggest change being the requirement for x64 CPUs.  The minimum hardware requirements are as follows:

• Any Intel Xeon or Pentium 4 64-bit processor
• Any AMD Opteron or Athalon 64-bit processor
• 1GB of RAM plus 7MB per mailbox
• 1.2 GB of available disk space on the drive on which you install Exchange
• 200 MB of available disk space on the system drive
• DVD-ROM Drive
• SVGA or higher-resolution monitor
• NTFS File System

Note: Exchange Server 2007 Beta 2 includes 32bit builds but the RTM will be x64 only. You also need KB904639 (for x64 systems) and KB868060 installed.

Exchange has always relied on IIS services, but Exchange 2007 requires less out of IIS and in some cases, IIS is not required at all. 

Exchange 2007 no longer requires the IIS SMTP and NNTP services installed as it has its own built in SMTP server and, for messages being transported between Exchange 2007 servers with the organization, uses MAPI. Depending on the role or roles installed on the server, different components are required. The following chart shows which additional services each role requires.

Role

Additional Components

Edge Transport

None

Hub Transport

None

Mailbox Server

Network COM+, IIS, World Wide Web

Client Access Server

World Wide Web

Unified Messaging Server

Speechify (installed by E2007 Setup)

Preparing Active Directory

As previously mentioned, the installer will do all the AD preparation automatically. That does not mean that you cannot do it manually, in fact I’d suggest doing it manually on the Schema Master while it is disconnected from the domain. That way, if something goes wrong while the schema is being extended you can simply blow away the server and seize the role on a different server.

Preparing Active Directory manually offers more options than before and there maybe more commands for you to run, depending on your current environment. If you are currently running any Exchange 2000 or 2003 server the first command you must run is

Setup.com /PrepareLegacyExchangePermissions

This command must be run under an account with Exchange Admins permissions and the domain must be able to communicate with all other domains in the forest while being run. Finally, you will need to wait for the permissions to replicate before continuing.

The next command will prepare the schema, and this means the account you run this command from, must be a member of the Schema Admins group as well as the Exchange Admins group. 

Setup.com /PrepareSchema

Figure 2: PrepareSchema

This command must also be run in the domain that contains the forests Schema Master, and again, you should wait for the changes to replicate throughout AD before continuing. Replmon, from the Support Tools, is a great tool you can use to determine when the changes have been replicated.

The third command that you need to run preps the current domain, adds the Exchange Universal Security Groups and configures the Exchange objects with AD. The command

Setup.com /PrepareAD

Figure 3: PrepareAD

This command requires different permissions, depending on your current configuration. You need to run this with Enterprise Admin privileges, and if you have any Exchange 2003 servers within your current organization, you need to be a member of the Exchange Organization Administrators group. Again you will need to wait for the changes to replicate before proceeding. You can check for this by looking for the following new Security Groups in the root domain in an OU called Exchange Universal Security Groups (EUSG).

• Exchange Organization Administrators
• Exchange Recipient Administrators
• Exchange View-Only Administrators
• Exchange Servers
• Exchange2003 Interop

The final step is optional and is only required to run if you have multiple domains within the forest. This command configures the other domain, or domains, in the forest. It does not need to be run on the domain that you run /PrepareAD in, but any additional domains will need this command run. You have three command line options with this command.

Setup.com /PrepareDomain – Prepares the current domain

Setup.com /PrepareDomain:FQDN of target domain to be prepped

Setup.com /PrepareAllDomains – Prepares all domains in the forest.

Once you have completed all the commands, you can verify that you are ready to start installing Exchange 2007 by looking for the following.

• The Microsoft Exchange Systems Objects container contains a global group called Exchange 12 Domain Servers
• The ESUG has the Exchange 12 Domain Servers global group as a member.
• The ESUG will have permissions to the Manage Auditing and Security Log settings on all DCs in all domains that the commands were run against.

Its being a while… crazy work schedule…

Now getting ready to leave again for 3 weeks in London.

Once that is complete i will working on forming the new South East Microsoft Messaging User Group. If you are interested in being part of this venture please let me know. Right now (thanks to the support of Nathan Winters from (www.mmmug.com) we are hoping to get support or backing from Microsoft in the South East to get this of the ground.

Let me know if you are interested in helping or being part of the group by leaving a comment here.

Thanks!

I only came across this product recently;

http://www.iskoot.com/index.php

A great utility for any skype user.. VOIP on your cell phone! You can install right to your cell phone (they give a complete list of all supported cell phones on their website) and make skype calls from your cell no matter where you are!

Check out all the details on their website…

Off Topic; but I cannot go without mentioning…

My wife “Allison” gave birth to a new baby girl this past weekend.

We are now the proud parents of “Anna Elizabeth Kinahan” & she is now a baby sister to Evin.

Born on 6/28/08 weighing 7lbs 12oz & 18.1? long.

Welcome to the world sweetheart!

Click on the link below if you would like a copy of the Microsoft Exchange Server 2007 Desktop Wallpaper...

http://msexchangeteam.com/attachment/427824.ashx

Courtesy of the good folks at msexchangeteam.com

Below is a script that you can copy and save as metacleaner.vbs on the root of the C:\ drive of the new DC on your domain. This script CANNOT be run from server that you cleaning up the Metadata on.

This should be used in conjunction with the previous post;

--------------------------------------------------

REM     This tool is furnished "AS IS". NO warranty is expressed or Implied.
on error resume next
dim objRoot,oDC,sPath,outval,oDCSelect,objConfiguration,objContainer,errval,ODCPath,ckdcPath,myObj,comparename
rem =======This gets the name of the computer that the script is run on ======
Set sh = CreateObject("WScript.Shell")
key= "HKEY_LOCAL_MACHINE"
computerName = sh.RegRead(key & "\SYSTEM\CurrentControlSet\Control\ComputerName\ComputerName\ComputerName")
rem === Get the default naming context of the domain====
set objRoot=GetObject("LDAP://RootDSE")
sPath = "LDAP://OU=Domain Controllers," & objRoot.Get("defaultNamingContext")
rem === Get the list of domain controllers====
Set objConfiguration = GetObject(sPath)
For Each objContainer in objConfiguration
outval = outval & vbtab &  objContainer.Name & VBCRLF
Next
outval = Replace(outval, "CN=", "")
rem ==Retrieve the name of the broken DC from the user and verify it's not this DC.===
oDCSelect= InputBox (outval,"Type the Name of the Problem Domain Controller","")
comparename = UCase(oDCSelect)
if comparename = computerName then
msgbox "The Domain Controller you entered is the machine that is running this script." & vbcrlf & "You cannot clean up the metadata for the machine that is running the script!",,"Metadata Cleanup Utility Error."
wscript.quit
End If
sPath = "LDAP://OU=Domain Controllers," & objRoot.Get("defaultNamingContext")
Set objConfiguration = GetObject(sPath)
For Each objContainer in objConfiguration
Err.Clear
ckdcPath = "LDAP://" & "CN=" & oDCSelect & ",OU=Domain Controllers," & objRoot.Get("defaultNamingContext")
set myObj=GetObject(ckdcPath)
If err.number <>0 Then
errval= 1
End If
Next
If errval = 1 then
msgbox "The Domain Controller you entered was not found in the Active Directory",,"Metadata Cleanup Utility Error."
wscript.quit
End If
abort = msgbox ("You are about to remove all metadata for the server " & oDCSelect & "! Are you sure?",4404,"WARNING!!")
if abort <> 6 then
msgbox "Metadata Cleanup Aborted.",,"Metadata Cleanup Utility Error."
wscript.quit
end if
oDCSelect = "CN=" & oDCSelect
ODCPath ="LDAP://" & oDCselect & ",OU=Domain Controllers," & objRoot.Get("defaultNamingContext")
sSitelist = "LDAP://CN=Sites,CN=Configuration," & objRoot.Get("defaultNamingContext")
Set objConfiguration = GetObject(sSitelist)
For Each objContainer in objConfiguration
Err.Clear
sitePath = "LDAP://" & oDCSelect & ",CN=Servers," &  objContainer.Name & ",CN=Sites,CN=Configuration," & objRoot.Get("defaultNamingContext")
set myObj=GetObject(sitePath)
If err.number = 0 Then
siteval = sitePath
End If   
Next
sFRSSysvolList = "LDAP://CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System," & objRoot.Get("defaultNamingContext")
Set objConfiguration = GetObject(sFRSSysvolList)
For Each objContainer in objConfiguration
Err.Clear
SYSVOLPath = "LDAP://" & oDCSelect & ",CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System," & objRoot.Get("defaultNamingContext")
set myObj=GetObject(SYSVOLPath)
If err.number = 0 Then
SYSVOLval = SYSVOLPath
End If
Next
SiteList = Replace(sSitelist, "LDAP://", "")
VarSitelist = "LDAP://CN=Sites,CN=Configuration," & objRoot.Get("defaultNamingContext")
Set SiteConfiguration = GetObject(VarSitelist)
For Each SiteContainer in SiteConfiguration
Sitevar = SiteContainer.Name
VarPath ="LDAP://OU=Domain Controllers," & objRoot.Get("defaultNamingContext")
Set DCConfiguration = GetObject(VarPath)
    For Each DomContainer in DCConfiguration
    DCVar = DomContainer.Name
    strFromServer = ""
    NTDSPATH =  DCVar & ",CN=Servers," & SiteVar & "," & SiteList
    GuidPath = "LDAP://CN=NTDS Settings,"& NTDSPATH
    Set objCheck = GetObject(NTDSPATH)
        For Each CheckContainer in objCheck
rem ====check for valid site paths =======================
        ldapntdspath = "LDAP://" & NTDSPATH
        Err.Clear
        set exists=GetObject(ldapntdspath)
            If err.number = 0 Then
                Set oGuidGet = GetObject(GuidPath)
                For Each objContainer in oGuidGet
                oGuid = objContainer.Name
                oGuidPath = "LDAP://" & oGuid & ",CN=NTDS Settings," & NTDSPATH 
                Set objSitelink = GetObject(oGuidPath)
                objSiteLink.GetInfo
                strFromServer = objSiteLink.Get("fromServer")
                ispresent = Instr(1,strFromServer,oDCSelect,1)
                    if ispresent <> 0 then
                    Set objReplLinkVal = GetObject(oGuidPath)
                    objReplLinkVal.DeleteObject(0)
                    else
                    end if
                next
                sitedelval = "CN=" & comparename & ",CN=Servers," & SiteVar & "," & SiteList
                if sitedelval = ntdspath then
                    Set objguidpath = GetObject(guidpath)
                    objguidpath.DeleteObject(0)
                    Set objntdspath = GetObject(ldapntdspath)
                    objntdspath.DeleteObject(0)
                    else
                end if
            End If
        next
    next
next
Set AccountObject = GetObject(ckdcPath)
temp=Accountobject.Get ("userAccountControl")
AccountObject.Put "userAccountControl", "4096"
AccountObject.SetInfo
Set objFRSSysvol = GetObject(SYSVOLval)
objFRSSysvol.DeleteObject(0)
Set objComputer = GetObject(ckdcPath)
objComputer.DeleteObject(0)
Set objConfig = GetObject(siteval)
objConfig.DeleteObject(0)
oDCSelect = Replace(oDCSelect, "CN=", "")
msgval = "Metadata Cleanup Completed for " & oDCSelect
msgbox  msgval,,"Notice."
wscript.quit

This document details steps to be taken to correct replication problems between Domain Controllers and also serves as a point of reference for forcefully removing a DC from the domain.
It is important to identify which DC holds the most recent updates of AD.  Check for recently created objects such as users or groups or machine accounts.  When removing the DC from the domain, any objects that only exist on this server will be lost.
As a naming convention this document will refer to ServerGood and ServerBad where ServerGood is the DC that will remain in the domain and ServerBad is the DC to be removed.
1.    Identify the bad server (ServerBad)
2.    On ServerBad stop the NTFRS service and KDC Service.
3.    On ServerBad run KerbTray resource kit utility and delete the Kerberos Certificates.
4.    On ServerGood, run Netdom Query FSMO and check for FSMO ownership.  Attempt to transfer all roles to ServerGood using AD Users and Computers
5.    If you are unable to transfer roles, seize all 5 FSMO roles.
Note Only seize the FSMO roles to the remaining Active Directory domain controllers if you are removing the FSMO role holder from the domain or forest.
To seize or transfer the FSMO roles by using Ntdsutil, follow these steps:
1.    On any domain controller, click Start, click Run, type ntdsutil in the Open box, and then click OK.
Note Microsoft recommends that you use the domain controller that is taking the FSMO roles.
2.    Type roles, and then press ENTER.
To see a list of available commands at any of the prompts in the Ntdsutil tool, type ?, and then press ENTER.
3.    Type connections, and then press ENTER.
4.    Type connect to server servername, where servername is the name of the server you want to use, and then press ENTER.
5.    At the server connections: prompt, type q, and then press ENTER again.
6.    Type seize role, where role is the role you want to seize. For a list of roles that you can seize, type ? at the Fsmo maintenance: prompt, and then press ENTER, or consult the list of roles at the beginning of this article. For example, to seize the RID Master role, you would type seize rid master. The one exception is for the PDC Emulator role, whose syntax would be "seize pdc" and not "seize pdc emulator".
Note All five roles need to be in the forest. If the first domain controller is out of the forest then seize all roles. Determine which roles are to be on which remaining domain controllers so that all five roles are not on only one server.
Microsoft recommends that you only seize all roles when the other domain controller is not returning to the domain, otherwise fix the broken domain controller with the roles.
Note If the domain controller that formerly held any FSMO role is not present in the domain and if it has had its roles seized by the earlier steps in this article, remove it from the Active Directory by following the procedure that is outlined in the following Microsoft Knowledge Base article: For additional information, click the following article number to view the article in the Microsoft Knowledge Base:
216498 HOW TO: Remove Data in Active Directory After an Unsuccessful Domain Controller Demotion
If the original domain controller with the FSMO roles is still online, transfer the roles. Type transfer role.
7.    After you seize or transfer the roles, type q, and then press ENTER until you quit the Ntdsutil tool.
Note Do not put the Infrastructure Master role on the same domain controller as the global catalog.
To check if a domain controller is also a global catalog server:
1.    Click Start, point to Programs, point to Administrative Tools, and then click Active Directory Sites and Services.
2.    Double-click Sites in the left pane, and then browse to the appropriate site or click Default-first-site-name if no other sites are available.
3.    Open the Servers folder, and then click the domain controller.
4.    In the domain controller's folder, double-click NTDS Settings.
5.    On the Action menu, click Properties.
6.    On the General tab, locate the Global Catalog check box to see if it is selected.
6.    Reboot ServerBad and verify that you can successfully log in under Active Directory Restore Mode.
7.    On ServerBad run DCPROMO /FORCEREMOVAL
Refer to MSKB 332199 for additional details if needed.
8.    ServerBad should now be in a workgroup.
9.    On ServerGood, execute the MetaCleaner.vbs script and select the ServerBad computer name to delete it from the metabase.
Note: if MetaCleaner.vbs is unavailable you can follow MSKB 216498.
10.    Launch the MMC and add the ADSIEdit snap-in.
Remove ServerBad from everything
Now that the NTDS Settings object has been deleted, you can delete the computer account, the FRS member object, the cname (or Alias) record in the _msdcs container, the A (or Host) record in DNS, the trustDomain object for a deleted child domain, and the domain controller.
1.    Use ADSIEdit to delete the computer account. To do this, follow these steps:
a.    Start ADSIEdit.
b.    Expand the Domain NC container.
c.    Expand DC=Your Domain, DC=COM, PRI, LOCAL, NET.
d.    Expand OU=Domain Controllers.
e.    Right-click CN=domain controller name, and then click Delete.
Note: you may need to expand the object and manually delete child objects to delete the computer account if you receive a message that you have insufficient rights to delete the computer account..
If you receive the "DSA object cannot be deleted" error when you try to delete the object, change the UserAccountControl value. To change the UserAccountControl value, right-click the domain controller in ADSIEdit, and then click Properties. Under Select a property to view, click UserAccountControl. Click Clear, change the value to 4096, and then click Set. You can now delete the object.
Note The FRS subscriber object is deleted when the computer object is deleted because it is a child of the computer account.
2.    Use ADSIEdit to delete the FRS member object. To do this, follow these steps:
a.    Start ADSIEdit.
b.    Expand the Domain NC container.
c.    Expand DC=Your Domain, DC=COM, PRI, LOCAL, NET.
d.    Expand CN=System.
e.    Expand CN=File Replication Service.
f.    Expand CN=Domain System Volume (SYSVOL share).
g.    Right-click the domain controller you are removing, and then click Delete.
3.    In the DNS console, use the DNS MMC to delete the A record in DNS. The A record is also known as the Host record. To delete the A record, right-click the A record, and then click Delete. Also delete the cname (also known as the Alias) record in the _msdcs container. To do so, expand the _msdcs container, right-click the cname, and then click Delete.
Important If this was a DNS server, remove the reference to this DC under the Name Servers tab. To do this, in the DNS console, click the domain name under Forward Lookup Zones, and then remove this server from the Name Servers tab.
Note If you have reverse lookup zones, also remove the server from these zones.
4.    If the deleted computer was the last domain controller in a child domain and the child domain was also deleted, use ADSIEdit to delete the trustDomain object for the child. To do this, follow these steps:
a.    Start ADSIEdit.
b.    Expand the Domain NC container.
c.    Expand DC=Your Domain, DC=COM, PRI, LOCAL, NET.
d.    Expand CN=System.
e.    Right-click the Trust Domain object, and then click Delete.
5.    Use Active Directory Sites and Services to remove the domain controller. To do this, follow these steps:
a.    Start Active Directory Sites and Services.
b.    Expand Sites.
c.    Expand the server's site. The default site is Default-First-Site-Name.
d.    Expand Server.
e.    Right-click the domain controller, and then click Delete.
11.    Remove all references to ServerBad in DNS forward and reverse lookup zones.
12.    Verify that ServerBad does not exist in AD Users and Computers.
13.    It is now safe to have ServerBad rejoin the domain and use DCPROMO to make it a DC again if needed

An important piece of info for anyone looking to attach storage to a server in excess of 2TB;

With Windows Server 2003 Service Pack 1 (SP1) and Windows XP 64-bit Edition (x64), these limits have changed.

Microsoft added support for 64-bit block numbers in the disk/class layer, using the new SCSI Commands included in the SCSI-3 Block Commands-2 command set. Microsoft also enabled GPT support for all Windows Server 2003 SP1 platforms. With this change, for example, a snapshot of a GPT partition on an Itanium-based machine can now be transported to a 32-bit machine for data mining or archiving purposes.

The new limits are as follows:

• Basic or dynamic volume size: 2⁶⁴ blocks = 2⁷³ bytes (too big to pronounce)
• Maximum NTFS file system size that can be realized on Windows: 256 TB

Note: Disk devices with more than 2 TB of disk space must be converted to GPT format for all of the disk space to be usable. If the device uses MBR format, the disk space beyond 2 TB will be unusable.

See more at: http://www.microsoft.com/whdc/device/storage/LUN_SP1.mspx#EFB

Truly the best resource there is on MS Clustering;

http://support.microsoft.com/kb/259267

The release of Microsoft Exchange Server 2007 Service Pack 1 (SP1) brings a wide variety of new features and functionality to Exchange 2007. The list of features we have added, which can be reviewed at What’s New in Exchange Server 2007 SP1, is quite impressive. There are new deployment options, new features and improvements for each server role, improved integration with other applications, such as Microsoft Office Communications Server (OCS) 2007, and even a new, third type of continuous replication.

Continue here.