January 2009 - Posts

If you only had a single storage group, the script in Exchange 2007 and Windows 2008: Online Exchange Backup (part 6 of 7) would not find any storage groups. The primary reason for that I always have a RSG too! :-) The fix is easy. In getStoragegroups, change the beginning few lines:

function getStorageGroups
{
	$count = 0
	#
	# locate the storage groups and their log files and system files
	#
	$colSG = get-StorageGroup -server $computername
	if ($colSG.Count -lt 1)
	else
	{
		write-host "No storage groups found on server $computername"
		return 1
	} 

to look like this:

function getStorageGroups
{
	$count = 0
	#
	# locate the storage groups and their log files and system files
	#
	$colSG = get-StorageGroup -server $computername
###	if ($colSG.Count -lt 1)
	if (($colSG -is [Microsoft.Exchange.Data.Directory.SystemConfiguration.StorageGroup]) -or
	    ($colSG -is [System.Object[]]))
	{
		## everything is good
	}
	else
	{
		write-host "No storage groups found on server $computername"
		return 1
	}

Until next time...

As always, if there are items you would like me to talk about, please drop me a line and let me know!

Posted by michael | with no comments

I've written several times about the inadvisability of having an Active Directory domain name that has a single-label. My most recent article was Wrapping Up SLDs and Exchange Server 2007 in April of 2008.

At that time, Ed Beck of Microsoft wanted to assure me that if customers found bugs, they should report them and Microsoft would investigate the issues and address the issues based on the standard engineering review decision process within Microsoft. That is, Microsoft was't closing the door on fixing problems with SLDs in Exchange 2007.

Now, the next version of Exchange, which is code-named E14, is in development. Yesterday, Ed emailed me and told me that Microsoft released a forward-looking statement indicating that they are investigating the SLD policy for E14 (Ed authored the article on the MS Exchange Team Blog: Next version of Exchange and Single Label Domain (SLD) policy under review).

I guess if I were you - and using an SLD - now would be the time to make yourself known! Feedback is accepted on the Exchange Team Blog site for quite a while after a posting. Let them know your opinion!

Until next time...

As always, if there are items you would like me to talk about, please drop me a line and let me know!

Posted by michael | with no comments

In the first five parts of this series, I've given you the background to understand how Exchange backup works when using VSS and how to acquire the necessary information from your Exchange server to know what you should back up. Today, I present to you a full-blown working script that will generate a full-backup of your Exchange 2007 Server on Windows Server 2008, verify that the backup is good using ESEUTIL, and flush the transaction logs for the Exchange storage groups if the backup is good.

The first five parts of the series were:

Part 1: Getting a List of Storage Groups in a PowerShell Script

Part 2: Getting a List of Stores in a PowerShell Script

Part 3: Exchange 2007 and Windows 2008: Offline Exchange Backup

Part 4: Volume Shadow Copy Services (VSS) and Exchange - The Basics

Part 5: Exchange 2007 and Windows 2008: Using Diskshadow for Online Exchange Backup

Now, before you ask - is this a supported backup tool? The answer is yes and no. VSS backups are a supported way to back up an Exchange server's databases. Diskshadow is a supported tool on Windows Server 2008. Is my script supported? No. Only so far as I find the time, energy, and effort to provide support for it. I can't warrant that it will work in your environment. It's worked everywhere I've tested it, that's all I can tell you. If you find a problem, let me know and I'll try to help, but there are no guarantees.

You won't find anything new in this script (from the prior postings in this series), except that the Diskshadow script is generated within the PowerShell script. This makes it easier when you run into a situation that you are using multiple volumes in your Exchange environment (which is a best practice for performance reasons).

The script takes three parameters:

$backupLocation - This is the volume and directory (or mountpoint) where the backup should go. It defaults to C:\Backups. You will probably need to change this for your environment.

$startLetter - This is the first letter that should be used by the script for exposing shadow copies as drive letters for the backup scripts. This defaults to g.

$startScript - This is a switch parameter. When set, the PowerShell script will initiate the backup using diskshadow.exe as soon as the script is built. The switch defaults to unset.

The #1 limitation of this script is that it backs up all storage groups on an Exchange server. I have plans to address that in a future revision.

The #2 limitation of this script is that it's "an ugly command line tool". I have plans to address that in a future revision.

This script will create a metadata file named (join-path $backupLocation "online-backup.cab") (That is C:\Backups\online-backup.cab by default). This file is used by diskshadow.exe for storing information required for restores. We will cover basic restores in part 7 of this series.

The cmd.exe script is stored as (join-path %TEMP% "online-backup.cmd"). The Diskshadow.exe script is stored as (join-path %TEMP% "online-backup.dsh").

On my server, I store PowerShell scripts in the c:\scripts folder, and name this particular script MBS-online-backup.ps1. A typical invocation is:

join-path "F:\ExchangeBackups" (get-date -uFormat "%Y-%m-%d-%H-%M-%S") |% { md $_ |% { ./MBS-online-backup.ps1 -backupLocation $_.FullName -startScript } }

This causes a unique directory to be created for each invocation of the backup script and for the script to be automatically run.

Granted, that's a dense for a beginner to understand. You can separate that into multiple lines quite easily:

$backupSubDir = get-date -uFormat "%Y-%m-%d-%H-%M-%S"
## As specified, the uFormat string means: yyyy-mm-dd-hh-mm-ss
## where the first 'mm' is the month number, and
## the second 'mm' is the minute number.
$backupDir = join-path "F:\ExchangeBackups" $backupSubDir
md $backupDir
./MBS-online-backup.ps1 -backupLocation $backupDir -startScript

And that is much easier to understand. Without further ado, here is the script:

##
## MBS-online-backup.ps1
##
## Michael B. Smith
## January, 2009
##
## This program generates an online VSS-based backup of an Exchange server
## (Exchange related files only) to a specified remote disk location.
##
## No warranties, express or implied, are available. It works for me. If
## you find errors or have problems, please feel free to let me know, but
## I can't guarantee that I can fix them.
##
## Feel free to use this in your own scripts. I would appreciate attribution.
##
Param(
	[string]$backupLocation = "C:\Backups",
	[string]$startLetter    = "g",
	[switch]$startScript    = $false
)

## $backupLocation is where the files and metadata go.

## $startLetter will contain the first letter we use to remap
## the volume letters contained in $volumes.

## $nl is the DOS newline character string

$nl = "`r`n"

## $volumes will contain the volume letters used by all named
## files and directories.

$volumes = @{}

## any storage group will contain:
## a] a system file directory
## b] a log file directory
## c] a filename for each database within the SG
##
## $pathPattern contains the dos patterns of files in the storage group

$pathpattern = @{}		### Exx.chk, Exx*.log, *.edb

## $storeList contains the filenames of the Exchange databases that need
## to be checked.

$storeList = @{}

## $letters contains the mapping between the original drive letter
## and the exposed driver letter in the shadow copy.

$letters = @{}

## $computerName contains the local computer's name

$computerName = $env:ComputerName

function buildRobocopyString($collection)
{
	$str = ""

	foreach ($filepath in $collection)
	{
		$file = split-path $filepath -leaf
		$path = split-path $filepath -parent
		#
		# the destination path is the source path appended to
		# the backup folder location.
		#
		$destpath = join-path $backupLocation $path.SubString(3, $path.Length - 3)
		#
		# the source path is the true path modified by the
		# letter of the exposed shadow copy
		#
		$letter = $letters.($path.SubString(0, 1))
		$subpath = $path.SubString(1, $path.Length - 1)
		$srcpath = "$letter$subpath"
		$str += "echo Copying " + $filepath + "..." + $nl
		$str += "robocopy " + '"' + $srcpath + '" "' + $destpath + 
		        '" "' + $file + '" /copyall /ZB >nul' + $nl
		$str += "if not errorlevel 0 goto :abort" + $nl
	}

	return $str
}

function buildESEUTILString($collection)
{
	$str = ""

	foreach ($path in $collection)
	{
		#
		# the destination path is the source path appended to
		# the backup folder location.
		#
		$path = $path.ToString()
		$destpath = join-path $backupLocation $path.SubString(3, $path.Length - 3)

		$str += "echo Checking " + $destpath + "..." + $nl
		$str += "call :checkit " + '"' + $destpath, '"' + $nl
		$str += "if not errorlevel 0 goto :abort" + $nl
	}

	return $str
}

function buildCMD
{
	$script = "@echo off" + $nl

	$script += buildRobocopyString $pathPattern.keys
	$script += $nl
	$script += buildESEUTILString $storeList.keys
	$script += $nl
	$script += "exit 0" + $nl
	$script += ":abort" + $nl
	$script += "exit 1" + $nl
	$script += $nl
	$script += ":checkit" + $nl
##	$script += "echo Checking %1" + $nl
	$script += "eseutil /k %1 >nul" + $nl
	$script += "if not errorlevel 0 exit 1" + $nl
	$script += $nl

	$scriptFile = join-path $env:temp "online-backup.cmd"
	$script | out-file $scriptFile -encoding ascii

	return $scriptFile
}

function writerOptimizationGarbage
{
	$script  = ""

	$script += "# verify presence of Exchange Writer" + $nl
	$script += "writer verify {76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}" + $nl
	$script += "# exclude system writer" + $nl
	$script += "writer exclude {e8132975-6f93-4464-a53e-1050253ae220}" + $nl
	$script += "# exclude IIS config writer" + $nl
	$script += "writer exclude {2a40fd15-dfca-4aa8-a654-1f8c654603f6}" + $nl
	$script += "# exclude ASR writer" + $nl
	$script += "writer exclude {be000cbe-11fe-4426-9c58-531aa6355fc4}" + $nl
	$script += "# exclude BITS writer" + $nl
	$script += "writer exclude {4969d978-be47-48b0-b100-f328f07ac1e0}" + $nl
	$script += "# exclude WMI writer" + $nl
	$script += "writer exclude {a6ad56c2-b509-4e6c-bb19-49d8f43532f0}" + $nl
	$script += "# exclude registry writer" + $nl
	$script += "writer exclude {afbab4a2-367d-4d15-a586-71dbb18f8485}" + $nl
	$script += "# exclude iis metabase writer" + $nl
	$script += "writer exclude {59b1f0cf-90ef-465f-9609-6ca8b2938366}" + $nl
	$script += "# exclude com+ regdb writer" + $nl
	$script += "writer exclude {542da469-d3e1-473c-9f4f-7847f01fc64f}" + $nl
	$script += "# exclude shadow-copy optimization writer (does not apply to exchange)" + $nl
	$script += "writer exclude {4dc3bdd4-ab48-4d07-adb0-3bee2926fd7f}" + $nl
	$script += $nl

	return $script
}

function buildDSH([string]$cmdfilename)
{
	write-host "Building backup script"

	$script  = ""
	$script += "# Diskshadow backup script." + $nl
##	$script += "set verbose on" + $nl
	$script += "set context persistent" + $nl
	$script += "set metadata " + (join-path $backupLocation "online-backup.cab") + $nl
	$script += $nl
	$script += writerOptimizationGarbage
	$script += "begin backup" + $nl
	$script += $nl

	foreach ($drive in $volumes.keys)
	{
		$script += "add volume " + $drive + ": alias shadow_" + $drive + $nl
	}

	$script += $nl + "create" + $nl + $nl

	foreach ($drive in $volumes.keys)
	{
		$script += "expose %shadow_" + $drive + "% " + $letters.$drive + ":" + $nl
	}

	$script += $nl
	$script += "exec " + $cmdfilename + $nl

	#
	# If the batch file from exec fails, diskshadow terminates without
	# executing any more commands.
	#
	$script += "end backup" + $nl

	foreach ($drive in $volumes.keys)
	{
		## remove the temporary shadow copy and unexpose the letter
		$script += "delete shadows exposed " + $letters.$drive + ":" + $nl
	}

	$script += $nl
	$Script += "exit" + $nl

	$scriptFile = join-path $env:temp "online-backup.dsh"

	$script | out-file $scriptFile -encoding ascii
	write-host "Diskshadow script file $scriptFile"
	return $scriptFile
}

function getStores
{
	## locate the databases, both mailbox and public folder

	$colMB = get-MailboxDatabase -server $computername
	$colPF = get-PublicFolderDatabase -server $computername

	## parse them for volumes too

	foreach ($mdb in $colMB)
	{
		if ($mdb.Recovery)
		{
			write-host ("Skipping RECOVERY MDB " + $mdb.Name)
			continue
		}
		write-host ($mdb.Name + "`t " + $mdb.Guid)
		write-host ("`t" + $mdb.EdbFilePath)
		write-host " "

		$pathPattern.($mdb.EdbFilePath) = 1
		$storeList.($mdb.EdbFilePath)   = 1

		$vol = $mdb.EdbFilePath.ToString().SubString(0, 1)
		$volumes.$vol += 1
	}

	foreach ($mdb in $colPF)
	{
		## a PF db can never be in a recovery storage group
		## which is why the Recovery check isn't done here

		write-host ($mdb.Name + "`t " + $mdb.Guid)
		write-host ("`t" + $mdb.EdbFilePath)
		write-host " "

		$pathPattern.($mdb.EdbFilePath) = 1
		$storeList.($mdb.EdbFilePath)   = 1

		$vol = $mdb.EdbFilePath.ToString().SubString(0, 1)
		$volumes.$vol += 1
	}

	return
}

function getStorageGroups
{
	$count = 0
	#
	# locate the storage groups and their log files and system files
	#
	$colSG = get-StorageGroup -server $computername
	if ($colSG.Count -lt 1)
	{
		write-host "No storage groups found on server $computername"
		return 1
	}

	## parse the pathnames for each SG to determine what
	## volumes it stores data upon and what directories are used

	foreach ($sg in $colSG)
	{
		if ($sg.Recovery)
		{
			write-host ("Skipping RECOVERY STORAGE GROUP " + $sg.Name)
			continue
		}

		$count++

		$prefix  = $sg.LogFilePrefix
		$logpath = $sg.LogFolderPath.ToString()
		$syspath = $sg.SystemFolderPath.ToString()

		write-host $sg.Name.ToString() "`t" $sg.Guid.ToString()
		write-host "`tLog prefix:      $prefix"
		write-host "`tLog file path:   $logpath"
		write-host "`tSystem path:     $syspath"

		## E00*.log
		$pathpattern.(join-path $logpath ($prefix + "*.log")) = 1

		$vol = $logpath.SubString(0, 1)
		$volumes.$vol += 1

		## E00.chk
		$pathpattern.(join-path $syspath ($prefix + ".chk")) = 1

		$vol = $syspath.SubString(0, 1)
		$volumes.$vol += 1

		write-host " "
	}

	if ($count -lt 1)
	{
		write-host "No storage groups found on server $computername"
		return 1
	}

	return 0
}

function validateArrays
{
	$drives = $volumes.keys
	if ($drives.Count -lt 1)
	{
		write-host "No disk volumes were found. Aborting."
		return 1
	}

	write-host ("There were " + $drives.Count.ToString() + " disk volumes for Exchange server $computername. They are:")
	foreach ($drive in $drives)
	{
		write-host "`t$drive"
	}

	write-host " "

	$paths = $pathPattern.keys
	if ($paths.Count -lt 1)
	{
		write-host "No paths were found. Aborting."
		return 1
	}

	write-host ("There are " + $pathPattern.Count.ToString() + " directories to be backed up. They are:")
	foreach ($directory in $pathPattern.keys)
	{
		write-host "`t$directory"
	}
	write-host " "

	$letter = $startLetter.Chars(0)

	foreach ($drive in $volumes.keys)
	{
		$letters.$drive = $letter
		$letter = [char]([int]$letter + 1)
	}

	return 0
}

	##
	## Main
	##

	if ((getStorageGroups) -eq 0)
	{
		getStores
		if ((validateArrays) -eq 0)
		{
			$scriptFile = buildCMD
			$scriptFile = buildDSH $scriptFile
			if ($startScript -and ($scriptFile.Length -gt 0))
			{
				diskshadow.exe -s $scriptFile
			}
		}
	}

Until next time...

As always, if there are items you would like me to talk about, please drop me a line and let me know!

If you hadn't noticed, I've been following a theme the last couple of months with some of the entries on this blog:

Part 1: Getting a List of Storage Groups in a PowerShell Script

Part 2: Getting a List of Stores in a PowerShell Script

Part 3: Exchange 2007 and Windows 2008: Offline Exchange Backup

Part 4: Volume Shadow Copy Services (VSS) and Exchange - The Basics

In this posting, which is part 5 of a 7-part series, I'll talk about a command-line tool which is new for Windows Server 2008: Diskshadow. The entire purpose behind Diskshadow is to allow a system administrator to harness the power of VSS from an easy-to-use utility. This is not the first utility from Microsoft that uses VSS (BETest and VShadow were both part of the VSS Software Development Kit), but it is the first supported utility for using VSS.

Let me begin by displaying a Diskshadow input file, and then I'll discuss it, line by line. In case it isn't obvious, you do not include line numbers inside a Diskshadow input file. They are shown here just for discussion. Also, the typical extension used for a Diskshadow input file is DSH. So, you might call this file offline-backup.dsh.

 1    # set verbose on
 2    set context persistent
 3    writer verify {76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}
 4    begin backup
 5    add volume c: alias shadow_c
 6    create
 7    expose %shadow_c% g:
 8    # exec offline-backup.cmd
 9    end backup
10    delete shadows exposed g:
11    exit

Line 1 begins with a hash-mark. This is indicative of a comment to the Diskshadow utility. Anything that occurs after the hash-mark on this line is ignored. However, if the hash-mark were not present, the command "set verbose on" would cause Diskshadow to output additional information as it determines the writers and components that will be included within the shadow copy.

Line 2 indicates that the shadow copy which is created will be persistent - that is, the shadow copy will continue to exist after the "end backup" (line 9) statement is executed. Shadow copies must be persistent in order to expose them (line 7). It is much easier to work with a shadow copy exposed as a drive letter than to use native format shadow copy names. For example, a typical shadow copy may be named \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy25 with a GUID of {e18b18b2-c8dd-4429-9996-af8d582616d8}.

Line 3 causes Diskshadow to verify that the particular writer having the named GUID is present on this computer. This GUID is the specific ID for "Microsoft Exchange Writer". This check effectively requires that this script is executed on an Exchange server. In order to see a list off all writers and their writer IDs, you can enter "vssadmin list writers" from a command prompt or within Diskshadow you can enter the "list writers" command. Note that you can also use the "writer exclude" command to ensure that a specific writer is not called as part of this backup.

Line 4 will start the actual VSS communication process by notifying all non-excluded writers to PrepareBackup. PrepareBackup was discussed in Volume Shadow Copy Services (VSS) and Exchange - The Basics.

Line 5 is used to identify a specific volume (could be a mount-point) that must be included in this VSS snapshot. You must identify all volumes that are involved in a backup. You learned how to do that for Exchange in Getting a List of Storage Groups in a PowerShell Script and Getting a List of Stores in a PowerShell Script.

Line 6 signals VSS to initiate Freeze and to create a snapshot. When the snapshot is complete, Diskshadow will signal VSS to Thaw. Freeze and Thaw were discussed in Volume Shadow Copy Services (VSS) and Exchange - The Basics.

Line 7 tells Diskshadow to expose the snapshot of a particular volume as a different drive letter (which may also be a mount point). This is primarily for ease-of-access, as I discussed for Line 2.

Line 8 is another comment. If it were not a comment, the EXEC command would cause Diskshadow to execute an external script. THAT SCRIPT is where a copy from a snapshot is actually created. You learned about how to generate that type of script in Exchange 2007 and Windows 2008: Offline Exchange Backup. If the script returns a non-zero value, then Diskshadow aborts.

Line 9 causes Diskshadow to signal VSS to send PostBackup to all involved writers. PostBackup was discussed in Volume Shadow Copy Services (VSS) and Exchange - The Basics.

Line 10 removes the snapshot associated with the drive letter G:, and deletes the drive mapping for G:. The storage space used by the snapshot is returned to the system.

Finally, line 11 terminates Diskshadow.

It is important to realize that after the CREATE statement finishes, what you have is a snapshot. It is not a backup, just a copy of the MFT and in-use bitmap for the disk drives that were included in the snapshot. You learned about the MFT and in-use bitmaps in Volume Shadow Copy Services (VSS) and Exchange - The Basics.

The script executed by line 8 is what creates copies of the files that are your actual backup.

You should also be aware that for any writer that was excluded from the backup, the files protected by that writer are still present in the snapshot; however they are CRASH CONSISTENT (i.e., in the same condition that would've happened if the power plug had been pulled on a server) not APPLICATION CONSISTENT (which is what you want for maximum recoverability).

In part 6 of this series, I will put all of the pieces together, and come up with a single PowerShell script that does "everything" to create an Exchange backup for you.

In part 7 of this series, I will cover doing simple restores of Exchange databases.

Until next time...

As always, if there are items you would like me to talk about, please drop me a line and let me know!

Introduction

The Volume Shadow Copy Service (VSS) was originally added to Windows Server 2003. The first version of Exchange Server to support VSS was Exchange Server 2003. The primary reason for the existence of VSS is to improve the performance of backup operations. VSS is only available for NTFS volumes.

I will not cover specific implementation details here, but concepts; some of those concepts will be specific to NTFS and Exchange specific and some will be general to VSS.

VSS backups (as implemented by Windows, not including the implementations by SAN/NAS/and other third-party vendors), are based on two primary concepts:

  1. A disk volume's in-use bitmap, and
  2. The Master File Table (MFT) for the volume.

A bitmap is a way of identifying the blocks of a disk volume which are being used vs. those blocks which are unused. In terms of implementation, it is usually an array (an ordered list of locations in a computer's memory), where each entry in that array represents the status of 32 blocks of that disk. In C-language terms:

    #define block_in_use(x) (drive_map_array [Floor((int)x / 32)] & (1 << ((int)x % 32)))

This assumes that the "element size" of the array is 32 bits per element. In the case of differing element sizes, adjust the value of 32 in the define to match the word size in bits per element.

Using this define, block_in_use() will return a non-zero value if the bit-field for a given block is set to 1. This means that the block is in use by some disk-related construct. If that bit-field is zero, block_in_use() will return a value of zero. This means that the block is not in use.

The in-use bitmap doesn't care about operating systems or file systems. It simply defines what blocks are available on a volume and what blocks are NOT available on a volume.

The MFT is both an operating system and file system specific construct. For a given disk volume, the MFT identifies what files/directories/etc. exist within that operating system/file system and what block(s) of the disk volume map to those file system constructs.

Every block contained within the MFT should be marked as in-use by the in-use bitmap.

Note that the in-use bitmap and the MFT work together. Neither provides a complete picture of a disk volume without the other. The MFT works per file system. Therefore, you can have multiple MFTs per disk volume. However, the in-use bitmap is per disk volume. You can only have a single in-use bitmap per disk volume.

When a particular file system needs to allocate a block on a disk volume, it calls a disk Application Programming Interface (API) that allows a block to be added to the MFT for the file system.

VSS Components

VSS has three main components:

  • the requester - the backup application
  • the provider - an operating system component that sits "on top of" the file system and mediates access to a VSS copy, while that VSS copy is active
  • the writer - an application component that has registered with the provider to enable support for an application that needs extra processing prior to a VSS backup (typically to flush buffers to disk)

A VSS Backup Overview

A VSS backup consists of five separate phases. Errors can occur and cause a backup to fail in any phase. The phase names are:

  1. PrepareBackup
  2. Freeze
  3. ...Backup
  4. Thaw
  5. PostBackup
When the requester wants to make a backup, it makes a PrepareBackup call to the VSS API. Part of this call is identifying the writers that need to be used to make the backup (e.g., if you are making an Exchange-only backup, you can exclude the COM+DB writer and the Registry writer; in fact you can exclude all writers except for the Exchange writer).

During PrepareBackup, VSS initializes each involved writer and indicates to the writer that a backup will be starting soon. After the return from PrepareBackup, the requester will make a Freeze call to the VSS API.

During the Freeze process, all involved writers will cause their subsystems to be application consistent on disk. That is, if buffers need to be flushed; they will be. If transaction logs need to be switched, they will be. Once a writer returns success to its Freeze call, it cannot make any modifications to disk until notified by VSS. This is enforced by the writer.

Once all writers are frozen, VSS creates a snapshot. A snapshot consists of, for all practical purposes, a copy of the MFT and the in-use bitmap of the disk. The entire file system is not processed, only a copy is made. That is what provides the speed in creating snapshots. Also note that only the involved writers have application consistency at this point. All other files are crash-consistent. A snapshot is exposed to the application as a mount-point. This mount point may be persistent or it may be ephemeral. A persistent mount point continues to exist after a VSS backup is complete.

After the snapshot is created, VSS will inform each involved writer to Thaw. At this time, applications are again allowed to make updates to the disk volume, using copy-on-write (which is done by the writer - the complexity of this is hidden from the application). That is, if a block in a file contained within the snapshot changes, then that block is not over-written on disk. Instead a new block is allocated and the MFT for that file will be updated to contain the new block. This allows a snapshot to maintain an unchanged image of the disk from when the snapshot occurred.

Now, the requester can take its backup from the snapshot. The requester may be as simple as cmd.exe's copy command or it may be a third-party backup application or it may be a SAN's special disk duplicating software. The requester is required to return a status back to VSS to indicate whether the backup was successful.

When the backup phase is complete, VSS will call each involved writer indicating a status of PostBackup. At this point each writer can do whatever clean up (if any) may be necessary. The writer is also informed of the status of the requester's backup. In some cases, this may affect PostBackup handling by the writer. For example, if a successful backup of a storage group occurred, the Exchange writer will flush the transaction logs for that storage group. If the backup failed, the transaction logs will not be flushed.

If the the snapshot was persistent, it will remain after PostBackup. If it was ephemeral, it will be deleted.

So, consider the example of backing up an Exchange server and only the Exchange portion of the server. The process will go like this:

  1. A backup application calls VSS and says that it wants to back up Exchange and only Exchange
  2. VSS calls the Exchange Writer with PrepareBackup.
  3. Asynchronously, Exchange initiates a transaction log switch and pauses the Lazy Writer process (which is responsible for flushing updates from the memory cache to the Exchange database) and the Log Writer process (which writes updates to a log file).
  4. VSS calls the Exchange Writer with Freeze
  5. Exchange waits for the transaction log switch to be complete and for the Lazy Writer and Log Writer processes to be paused
  6. VSS creates the snapshot
  7. VSS calls the Exchange Writer with Thaw
  8. Exchange unpauses the Lazy Writer and the Log Writer processes
  9. The backup application will back up all system files (Exx.CHK for each storage group), all log files (Exx*.log for each storage group), and all database files (*.EDB for each database) and return success or failure back to VSS
  10. VSS calls the Exchange Writer with PostBackup with the status of the backup
  11. If the backup was successful, transaction log files will be flushed
  12. The backup application disconnects from VSS and the backup is complete

As you can see, while there are a number of steps involved in the process it really isn't that complicated. Given a little help (in terms of a programmatic interface to VSS), it shouldn't be that hard to back up an Exchange server.

We'll talk about that in our next article in this series.

Until next time...

As always, if there are items you would like me to talk about, please drop me a line and let me know!

Posted by michael | 7 comment(s)
Filed under: ,

In May of 2008, I wrote the article SBS 2003 Hardware Migration/Upgrade. Since then, I've been asked many times about my process for doing a SBS 2003 hardware upgrade. In general, I just have to say "I follow the steps".

As I recommended in my original article, if the Microsoft white paper isn't detailed enough for you, I recommend SBS MVP Jeff Middleton's SBS Migration Tools.

However, this weekend I had the opportunity to upgrade the hardware for another client of mine, and I wrote down each step as I did it. This list of steps may encourage you to NOT do this. :-) There are many opportunities for error. This is a simple list of steps - if you don't know what the shorthand means - you probably shouldn't be doing it! :-P Some of these one-line steps can consume quite a bit of time (e.g., "move wss" - the process is an entire white paper all on its own).

I execute this process in three phases. Phase I is basically "install the software on the new hardware." Phase II is "configure the software and prepare for migration." Phase III is "complete the migration."

Phase I

-1] basic SBS 2003 RTM install
0] Join to AD domain
1] Dcpromo
2] Install DNS and DHCP
3] Change to AD integrated DNS
4] Update NIC(s)
5] move fsmo roles
6] update setup.sdb per  http://theessentialexchange.com/blogs/michael/archive/2008/05/18/sbs-2003-hardware-migration-upgrade.aspx
7] Complete the SBS 2003 install
8] install Server 2003 sp1 (WindowsServer2003-KB889101-SP1-x86-ENU.exe)
9] Install kb 930045 (WindowsServer2003-KB930045-v5-x86-ENU.exe)
10] install WSS 2.0 sp1 (WSS2003SP1-kb841876-fullfile-enu.exe)
11] install Exchange 2003 sp1 (E3SP1ENG.exe)
12] install Windows XP sp2 for client deployment (SBS2003-KB891193-X86-ENU.EXE)
13] install SBS 2003 sp1 (SBS2003-KB885918-SP1-X86-ENU.EXE)
14] install Server 2003 sp2 (WindowsServer2003-KB914961-SP2-x86-ENU.exe)
15] install Exchange 2003 sp2 (E3SP2ENG.EXE)
16] Install kb 943494 (WindowsServer2003-KB943494-v4-x86-ENU.exe)
17] Install kb 930045 (WindowsServer2003-KB930045-v5-x86-ENU.exe)
18] install Resource Kit Tools (rktools.exe)
19] install Server Support Tools (suptools.msi)
20] install kb 943545 (WindowsServer2003-KB943545-x86-ENU.exe)
21] install Windows-Update/Microsoft-Update patches
22] install OpenManage/Server management tools
23] install FileserverTweaks.reg
24] move fsmo back (only domain fsmo, leave forest alone)

Phase II

1] configure remote access (ie, vpn)
2] activate server
3] add client licenses
4] configure SBS monitoring
5] configure exchange server
                Copy Database Size limit - http://technet.microsoft.com/en-us/library/aa998066.aspx
                Verify server property configurations
                Change Offline Address List server for all Offline Address Lists
                Update Recipient Update Service Config
                Copy SMTP Connector / Default SMTP Virtual Server
                Replicate public folders
6] install AV Server
7] install AV Client
8] move ssl certs
9] verify RPC/HTTPs config
10] set up new backup
11] move printers
12] move shares
13] initial file copy 

On old server: 
1] Install kb 943494 (WindowsServer2003-KB943494-v4-x86-ENU.exe)
2] Install kb 930045 (WindowsServer2003-KB930045-v5-x86-ENU.exe)
3] install kb 943545 (WindowsServer2003-KB943545-x86-ENU.exe)

Phase III

1] move fsmo
2] move mailboxes
3] move DHCP
4] move a/v clients
5] move WSS/SharePoint
6] move websites
7] move wsus
8] check/move Scheduled Tasks
9] move files
10] cut-overUntil next time...

As always, if there are items you would like me to talk about, please drop me a line and let me know!

Posted by michael | 1 comment(s)

In my article Getting a List of Stores in a PowerShell Script you learned how to obtain a list of all the files involved for the Exchange database stores on a particular Exchange server. In the preceding article, Getting a List of Storage Groups in a PowerShell Script, you learned how to obtain a list of all the files unique to the Exchange storage groups on a particular Exchange server.

As a part of both of those articles, you learned how to create a list of the volumes used by the files in the storage groups and in the database stores.

Now that we have that information, what can we do with it?

Easy! We can generate a script that can create an offline backup of our Exchange databases. In future articles, you'll learn how to turn this offline backup into an online backup, using VSS (the Volume Shadow Copy Service).

As a quick reminder, the following global objects are important and were introduced in the earlier articles of this series:

$volumes - a hash array containing the disk volumes used by the Exchange storage groups and database stores

$pathPattern - a hash array containing a list of all the regular-expression patterns required to back up all the files involved for all Exchange storage groups and database stores

getStores - a function populating $volumes and $pathPattern for the files used by Exchange database stores

getStorageGroups - a function populating $volumes and $pathPattern for the files used by Exchange storage groups

validateArrays - a function verifying that the $volumes and $pathPattern arrays are not empty; the function returns zero if the main program should proceed.

A utility that we have not previously discussed is robocopy. Robocopy was introduced as a part of the Windows 2000 Server Resource Kit. Among other features, it copies large files as quickly as possible, much more quickly than the cmd.exe copy and xcopy. Robocopy is a standard utility in Windows Vista and Windows Server 2008.

Two additional global variables need to be introduced:

$destination - the directory below which backups will be stored; in the case of Exchange backups, the directory structure is reproduced identically. For example, if $destination is "C:\Backups" and the file "C:\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group\E00.CHK" is a file to be backed up, then the destination file name will be "C:\Backups\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group\E00.CHK".

$nl - a DOS newline

So, after all the preparation we've already done, an offline backup script actually turns out to be quite simple. The PowerShell script below will generate a DOS script to be executed by cmd.exe. Robocopy will copy all relevant files to the backup location specified by $destination. If all copies succeed then the script succeeds. If any copy fails, the script aborts.

A couple of things to be careful of - this script actually executes the backup! To do that, in an offline mode, the Microsoft Exchange Information Store service must be stopped. When that service is stopped, Exchange is basically down. So...don't run this on your production system without commenting out the line that starts with cmd.exe (unless you are actually doing the offline backup).

Secondly, offline backups do not purge transaction logfiles. We'll need to learn how to do an online backup before we can make that happen.

Finally, the out-file cmdlet uses an unusual parameter: "-encoding ascii". This is because cmd.exe does not understand Unicode files (which is the default for out-file). Something to remember for your own scripts!

  
    $destination = "C:\backups"

    $nl = "`r`n"

    function buildRobocopyString($collection)
    {

        $str = ""

        foreach ($filepath in $collection)
        {
            $file = split-path $filepath -leaf
            $path = split-path $filepath -parent
            #
            # the destination path is the source path appended to
            # the backup folder location.
            #
            $destpath = join-path $destination $path.SubString(3, $path.Length - 3)

            $str += "echo Copying " + $file + "..." + $nl
            $str += "robocopy " + '"' + $path + '" "' + $destpath + 
                '" "' + $file + '" /copyall /ZB >nul' + $nl
            $str += "if not errorlevel 0 goto :abort" + $nl
        }

        return $str
    }

    function buildCMD
    {
        $script = "@echo off" + $nl

        $script += 'net stop "Microsoft Exchange Information Store" /y' + $nl

        $script += buildRobocopyString $pathPattern.keys
	$script += $nl
        $script += 'net start "Microsoft Exchange Information Store"' + $nl
        $script += "exit 0" + $nl
        $script += ":abort" + $nl
        $script += "exit 1" + $nl

        $script | out-file (join-path (gc env:temp) "offline-backup.cmd") -encoding ascii
        cmd.exe /c (join-path (gc env:temp) "offline-backup.cmd")
    }

    #
    # Main
    #

    if ((getStorageGroups) -eq 0)
    {
        getStores
        if ((validateArrays) -eq 0)
        {
            buildCMD
        }
    }

Until next time...

As always, if there are items you would like me to talk about, please drop me a line and let me know!

Posted by michael | 3 comment(s)
Filed under: , ,