April 2009 - Posts

It has been suggested to me that my series on backing up Exchange Server 2007 on Windows Server 2008 was so complicated that the content was truly inaccessible for the novice admin. For that, I apologize. At heart, I am a techie kind of guy and I spend a lot of time trying to make complicated things easy - in my blog articles, my magazines articles, and in the presentations I make at various conferences.

So, to make up for that, without any technical discussion whatsoever, I present my GUI solution (still PowerShell based) for backing up Exchange Server 2007 on Windows Server 2008. With the exception of the forms-based handling, all of the technical infrastructure has been discussed here and in article preceding that article.

The GUI solution requires .NET 2.0, but that's already installed on any Exchange Server 2007 computer.

To use the backup script:

  1. Download the zip file to a directory for PowerShell scripts on the Exchange Server you want to back up
  2. Extract the two files contained in the zip file into that directory
  3. Create (or identify) a directory where you want backups to go
  4. Identify the first free drive letter on the server
  5. Modify the MBS-GUI-Exchange-backup.ps1 script parameter block to insert those two parameters
  6. Execute the script (from PowerShell, move to the directory where you extracted the scripts and type in ./MBS-GUI-Exchange-backup.ps1)

That's it.That's all it takes.

Down the script MBS-GUI-Exchange2007-Backup.zip.

Just one tiny technical comment: if you are on Exchange 2003, it would be relatively easy to modify this script to use BEtest to execute VSS backups for Exchange 2003.

Until next time...

If there are things you would like to see written about, please let me know!

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

I dealt with the importance of the userPrincipalName in one of my very early blog postings, dated May 26, 2004: The User Principal Name and You.

While my company has changed, the basic information contained within that post has not changed at all.

I would add one fact: the current Active Directory forest domain is an implied userPrincipalName domain and is not reflected in the list of userPrincipalName domains (also called uPNSuffixes) that are presented in such tools as Active Directory Domains and Trusts. The Active Directory Users and Computer tool is aware of this, and will present it as an option when configuring new user objects.

This PowerShell code handles the addition, reporting, and elimination of UPN suffixes:

#
# userPrincipalName processing routines
#
# Michael B. Smith
# michael@smithcons.com
# April 6, 2009
#
[int] $ADS_PROPERTY_CLEAR	= 1
[int] $ADS_PROPERTY_UPDATE	= 2
[int] $ADS_PROPERTY_APPEND	= 3
[int] $ADS_PROPERTY_DELETE	= 4

function get-ConfigurationPartition
{
	$rootdse  = [ADSI]"LDAP://RootDSE"
	$configNC = $rootdse.ConfigurationNamingContext
	$rootdse  = $null

	$partition = [ADSI]("LDAP://CN=Partitions," + $configNC)

	return $partition
}

function get-UPN
{
	$config = get-ConfigurationPartition
	$suffix = $config.uPNSuffixes
	$config = $null

	return $suffix
}

function test-UPN([string]$upn)
{
	$suffixes = get-UPN

	if (!$suffixes)
	{
		return $false
	}

	if (($suffixes -is [System.String]) -and ($suffixes -eq $upn))
	{
		return $true
	}

	foreach ($suffix in $suffixes)
	{
		if ($suffix -eq $upn)
		{
			return $true
		}
	}

	return $false
}

function new-UPN([string]$upn)
{
	if (test-UPN $upn)
	{
		write-error "$upn already exists"
	}
	else
	{
		$config = get-ConfigurationPartition
		$config.PutEx($ADS_PROPERTY_APPEND, "uPNSuffixes", @($upn))
		$config.SetInfo()
		$config = $null
	}
}

function remove-UPN([string]$upn)
{
	if (test-UPN $upn)
	{
		$config = get-ConfigurationPartition
		$config.PutEx($ADS_PROPERTY_DELETE, "uPNSuffixes", @($upn))
		$config.SetInfo()
		$config = $null
	}
	else
	{
		write-error "$upn doesn't exist"
	}
}

Until next time...

If there are things you would like to see written about, please let me know!

Posted by michael | with no comments

In my first article on Multi-valued Parameters in PowerShell, I discussed a certain class of array parameters that Exchange 2007 uses many times - the [System.Object[]] (i.e., array of arbitrary elements) class for RemoteIpRanges.

Unfortunately, that isn't the only multi-valued type used by PowerShell for Exchange Server 2007. There are actually quite a few of them.

Another type that comes up fairly often is SourceTransportServers. This is used by the Set-SendConnector cmdlet among others. It is a collection of a specific type of objects that Exchange 2007 refers to as ADobjectIDs.

An ADobjectID is actually quite similar to a System.DirectoryServices.DirectoryEntry - however, in comparison, this type has very few populated properties. The fact that the property list for ADobjectID is quite small indicates the reason why Exchange uses this type instead of System.DirectoryServices.DirectoryEntry - the population of a few types is much more efficient than the population of all the types present for a DirectoryEntry.

Populating and updating SourceTransportServers is a common idea, especially when you are using provisioning scripts to completely deploy new servers. Here is an example of PowerShell code that you can use to do this:

$newhub = Get-ExchangeServer "newhubserver"
$adobject = New-Object Microsoft.Exchange.Data.Directory.ADobjectID $newhub.distinguishedName

$a = Get-SendConnector "Internet Email"
$a.SourceTransportServers.Add($adobject)

$a | Set-SendConnector

Until next time...

If there are things you would like to see written about, please let me know!

Posted by michael | with no comments