Determining the Exchange Version – without using Get-ExchangeServer

If you write lots of Exchange scripts (as I do), and have several different versions of Exchange on which you need to run those scripts (as I do); you soon see the need for being able to determine what version of Exchange a particular server is running – and you may need to do this outside of the Exchange Management Shell.

This may be necessary because of different behaviors that are required with the Exchange Management Shell depending on the version of Exchange. It also may be required because the version of Exchange pre-dates the Exchange Management Shell (i.e., Exchange 2003). As an additional rationale, your script may need to load the Exchange Management Shell and cannot do that properly without knowing the version of Exchange that is being targeted (the process differs between Exchange 2007 and Exchange 2010).

Thus, I've written a couple of functions that I wrap in a script to give me that information. Get-ExchangeServer, the function, returns a simple object containing the name of the server examined, plus the version of Exchange that is running on that server. That is:

struct result {

string Name;

string Version;

}

If the result of the function is $null, then the version could not be determined and the server targeted either does not exist or is (very likely) not running Exchange. If the server does not exist (or the firewall on the server prevents remote management via WMI) then an error is displayed.

The version information about Exchange is stored in the registry of each Exchange server. The script below shows some techniques for accessing the registry to obtain string (reg_sz) and short integer (reg_dword) values while using PowerShell. Note that PowerShell has multiple mechanisms for accessing this information, including the so-called Registry Provider. I personally find using the WMI functions to be a bit easier to handle.

You can include these functions directly into your PowerShell profile, or you can dot-source the function on an as-needed basis.

Without further ado, enjoy!


###
### Get-ExchangeVersion
###
### Return the version of the specified Exchange server
###

Set-StrictMode -Version 2.0

$HKCR = 2147483648
$HKCU = 2147483649
$HKLM = 2147483650

function RegRead
{
	Param(
		[string]$computer,
		[int64] $hive,
		[string]$keyName,
		[string]$valueName,
		[ref]   $value,
		[string]$type = 'reg_sz'
	)

	try {
		$wmi = [wmiclass]"\\$computer\root\default:StdRegProv"
		if( $wmi -eq $null )
		{
			return 1
		}
	}
	catch {
		##$error[0]
		write-error "Could not open WMI access to $computer"
		return 1
	}

	switch ( $type )
	{
		'reg_sz'
			{
				$r = $wmi.GetStringValue( $hive, $keyName, $valueName )
				$value.Value = $r.sValue
			}
		'reg_dword'
			{
				$r = $wmi.GetDWORDValue( $hive, $keyName, $valueName )
				$value.Value = $r.uValue
			}
		default
			{
				write-error "Unsupported type: $type"
			}
	}

	$wmi = $null

	return $r.ReturnValue
}

function Get-ExchangeVersion
{
	Param(
		[string]$computer = '.'
	)

	if( $computer -eq '.' )
	{
		$computer = $env:ComputerName
	}

	## Exchange vNext (assumption!)
	## HKLM\Software\Microsoft\ExchangeServer\v15\Setup
	## MsiProductMajor (DWORD 15)

	## Exchange 2010
	## HKLM\Software\Microsoft\ExchangeServer\v14\Setup
	## MsiProductMajor (DWORD 14)

	## Exchange 2007
	## HKLM\SOFTWARE\Microsoft\Exchange\Setup
	## MsiProductMajor (DWORD 8)

	## Exchange 2003
	## HKLM\SOFTWARE\Microsoft\Exchange\Setup
	## Services Version (DWORD 65)

	$v = 0

	$i = RegRead $computer $HKLM 'Software\Microsoft\ExchangeServer\v15\Setup' 'MsiProductMajor' ( [ref] $v ) 'reg_dword'
	if( ( $i -eq 0 ) -and ( $v -eq 15 ) )
	{
		$obj = "" | Select Name, Version
		$obj.Name = $computer
		$obj.Version = 'vNext'
		return $obj
	}

	$i = RegRead $computer $HKLM 'Software\Microsoft\ExchangeServer\v14\Setup' 'MsiProductMajor' ( [ref] $v ) 'reg_dword'
	if( ( $i -eq 0 ) -and ( $v -eq 14 ) )
	{
		$obj = "" | Select Name, Version
		$obj.Name = $computer
		$obj.Version = '2010'
		return $obj
	}

	$i = RegRead $computer $HKLM 'Software\Microsoft\Exchange\Setup' 'MsiProductMajor' ( [ref] $v ) 'reg_dword'
	if( ( $i -eq 0 ) -and ( $v -eq 8 ) )
	{
		$obj = "" | Select Name, Version
		$obj.Name = $computer
		$obj.Version = '2007'
		return $obj
	}

	$i = RegRead $computer $HKLM 'Software\Microsoft\Exchange\Setup' 'Services Version' ( [ref] $v ) 'reg_dword'
	if( ( $i -eq 0 ) -and ( $v -eq 65 ) )
	{
		$obj = "" | Select Name, Version
		$obj.Name = $computer
		$obj.Version = '2003'
		return $obj
	}

	### almost certainly not an Exchange server

	return $null
}

 

Enumerating networks and building routes with PowerShell

I've been working with a company that is in the process of setting up a remote datacenter for disaster recovery. They brought me in to help design their Exchange cross-site resilience, and I've been helping them with a few other things too.

Primary connectivity between the primary datacenter and the remote datacenter is via an L2TP tunnel, nailed up and encrypted, across the public Internet, using RRAS.

With over 300 servers in the primary datacenter and over 100 servers targeted in the remote datacenter, we needed a way to set up the proper routes for each server farm to access the other (in both cases, the default gateway is a TMG array).

I decided that I could do that in a few lines of PowerShell. Truth be told, the basic functionality is pretty simple – you iterate through the computers you are examining, look at the wired network interfaces on those computers, see those that have a particular source IP address, and give them a route to the destination network.

However – and as always, the devil is in the details – It Ain't That Simple (IATS – HAH!).

First of all, Active Directory was used as the source of computers. That's great! However, there are computers in AD that aren't in DNS. I have no clue how that happened, but one can surmise that the computers were cut off, their IP addresses reassigned, and the computer object never removed from AD. That's one condition we have to deal with.

Secondly, as a corollary to the above, workgroup computers aren't found at all. With the solution presented here, there were already DNS entries for these computers (and there were only a handful of them), so we temporarily created computer objects for them in AD.

Third, we found some computers have bad IP addresses (specifically 0.0.0.0). Again, I have no clue how that happened, but those have to be filtered out.

Fourth, group policies in this organization aren't applied very logically. That's not what they called me in for, so I had little say. Regardless, a number of computer did not have remote management enabled, thus preventing remote examination of their configuration and remote changes to their configuration. Detection of computers without remote management thus became something the script had to deal with.

Fifth, we had first decided to use 'ping' to determine the accessibility of the computers as part of the discovery process. Well, fewer than half of the computers allowed 'ping' through their firewalls, so that solution had to be summarily discarded. In order to determine accessibility, we actually had to attempt to access the computers.

Sixth, and this is actually a downstream symptom of the issue above, on some servers remote management generates an error. Those servers need to be detected and repaired.

Seventh, and finally, some servers have multiple IP addresses. This may mean that they are already being used as RRAS servers and they need human intelligence to determine whether a route change should be applied.

I didn't use "route add" because in some situations "route add" is known to fail, and "netsh interface ipv4 add route" is preferred.

The resulting utility script is not particularly pretty. But it's very useful and the techniques illustrated are likely to be useful for you in your scripting needs too. So, I present it for your pleasure. 🙂


[string] $nl = "`r`n"

$HKCR = 2147483648
$HKCU = 2147483649
$HKLM = 2147483650

$script:badIP         = @()
$script:commands      = @()
$script:cannotping    = @()
$script:cannotresolve = @()
$script:cannotmanage  = @()
$script:warningmsg    = @()

function msg
{
	$str = ''

	foreach( $arg in $args )
	{
		$str += $arg + ' '
	}
	Write-Host $str
}

function RegRead
{
	Param(
		[string]$computer,
		[int64] $hive,
		[string]$keyName,
		[string]$valueName,
		[ref]   $value,
		[string]$type = "REG_SZ"
	)

	$wmi = [wmiclass]"\\$computer\root\default:StdRegProv"
	if( $wmi -eq $null )
	{
		$script:cannotmanage += $computer
		return 1
	}

	$r = $wmi.GetStringValue( $hive, $keyName, $valueName )
	$value.Value = $r.sValue

	$wmi = $null

	return $r.ReturnValue
}


function test-ping( [string]$server )
{
	[string]$routine = "test-ping:"

	trap 
	{
		# we should only get here if the New-Object fails.

		write-error "$routine Cannot create System.Net.NetworkInformation.Ping for $server."
		return $false
	}

	$ping = New-Object System.Net.NetworkInformation.Ping
	if( $ping )
	{
		trap [System.Management.Automation.MethodInvocationException] 
		{
			###write-error "$routine Invalid hostname specified (cannot resolve $server)."
			msg "...cannot resolve $server in DNS"
			$script:cannotresolve += $server
			return $false
		}

		for( $i = 1; $i -le 2; $i++ )
		{
			$rslt = $ping.Send( $server )
			if( $rslt -and ( $rslt.Status -eq [System.Net.NetworkInformation.IPStatus]::Success ) )
			{
				### msg "$routine Can ping $server. Successful on attempt $i."
				$ping = $null
				return $true
			}
			sleep -seconds 1
		}
		$ping = $null
	}

	###write-error "$routine Cannot ping $server. Failed after 5 attempts."
	msg "...cannot ping $server"
	$script:cannotping += $server

	return $false
}

### 
### Main
###

$start = (get-date).DateTime.ToString()
msg 'Begin' $start

ipmo ActiveDirectory
$computers = Get-AdComputer -Filter * -SearchBase "OU=Servers,DC=example,DC=com" -ResultSetSize $null | Select DnsHostName
msg "There are $($computers.Count) computers to check"
$computerCount = 0
foreach( $computer in $computers)
{
	$computerName = $computer.DnsHostName
	$computerCount++
	msg "Checking $computername... ($computerCount of $($computers.Count))"

#	if( -not ( test-ping $computerName ) )
#	{
#		###msg '...cannot resolve or ping'
#		msg ' '
#		continue
#	}

	### server IP addresses - I only care about IPv4
	$serverIPv4   = @()
	$serverIPname = @()

	$nicSettings = gwmi Win32_NetworkAdapterSetting -EA 0 -ComputerName $computerName
	if( $nicSettings -eq $null )
	{
		msg "...cannot access $computername"
		msg " "
		$script:cannotresolve += $computername
		continue
	}

	foreach( $nicSetting in $nicSettings )
	{
		### msg "Element=" $nicSetting.Element ## is of type Win32_NetworkAdapter
		if( $nicSetting.Element -eq $null )
		{
			msg "...netSetting.Element is null"
			continue
		}

		$nicElement = [wmi] $nicSetting.Element
		if( $nicElement -eq $null )
		{
			msg "...nicElement is null"
			continue
		}

		if( $nicElement.AdapterType -eq "Ethernet 802.3" )
		{
			### msg "Setting=" $nicSetting.Setting
			$nicConfig = [wmi] $nicSetting.Setting ## is of type Win32_NetworkAdapterConfiguration
			$nicGUID = $nicConfig.SettingID
			### msg "NicGUID=" $nicGUID
			### msg "NIC IPEnabled=" $nicConfig.IPEnabled.ToString()
			if( $nicConfig.IPEnabled -eq $true )
			{
				$returnValue = $true ## there is at least one valid NIC

				$hive = $HKLM
				$keyName = "System\CurrentControlSet\Control\Network\" +
					"{4D36E972-E325-11CE-BFC1-08002BE10318}\" + 
					$nicGUID + 
					"\Connection"
				$valueName = "Name"

				$name = ''
				$result = RegRead $computerName $hive $keyName $valueName ( [ref] $name ) 'reg_sz'
				if( $result -ne 0 )
				{
					$name = ""
				}

				###msg "NIC name:" $name

				$script:arrNicName += $name
				foreach( $ip in $nicConfig.IPAddress )
				{
					if( $ip.IndexOf( ':' ) -ge 0 )
					{
						$script:arrIPListPublic_v6 += $ip
						###msg "IPv6 address " $ip
					}
					else
					{
						$script:arrIPListPublic_v4 += $ip
						$serverIPv4   += $ip
						$serverIPname += $name
						###msg "IPv4 address:" $ip
					}
				}
			}
			$nicConfig = $null
		}
		$nicElement = $null
	}
	$nicSettings = $null

	$limit = $serverIPv4.Count - 1

	$allowedAddresses = 0
	for( $i = 0; $i -le $limit; $i++ )
	{
		$ip = $serverIPv4[ $i ]
		$name = $serverIPname[ $i ]

		if( $ip.Length -lt 10 )
		{
			$script:badIP += "$computerName $name $ip"
		}
		elseif( $ip.SubString( 0, 10 ) -eq "10.129.59." )
		{
			msg "*** YES - $computerName is on the server room secure network using NIC '$name' ***"
			$cmd = 'netsh -r ' + $computerName + 
				' interface ipv4 add route 10.129.68.0/22 "' + $name + '" 10.129.59.104'
			$script:commands += $cmd
			$allowedAddresses++
		}
		elseif( $ip.SubString( 0, 10 ) -eq "10.129.68." )
		{
			msg "*** YES - $computerName is on the datacenter network using NIC '$name' ***"
			$cmd = 'netsh -r ' + $computerName + 
				' interface ipv4 add route 10.129.59.0/20 "' + $name +'" 10.129.68.7'
			$script:commands += $cmd
			$allowedAddresses++
		}
	}
	if( $allowedaddresses -gt 1 )
	{
		msg "*** WARNING ***"
		$m = "$computerName has more than one IPv4 address. It may require extra configuration."
		msg $m
		$script:warningmsg += $m
		msg "*** WARNING ***"
	}

	if( $allowedaddresses -eq 0 )
	{
		msg "...no 10.129.59.0/24 or 10.129.68.0/24 IP addresses found on this computer (out of $($serverIPv4.Count))"
	}

	msg " "
}

msg "List of computers and NICs with bad IP addresses ($($script:badIP.Count))"
$script:badIP
' '

msg "List of computers in AD who cannot be accessed ($($script:cannotresolve.Count))"
$script:cannotresolve
' '

#msg "List of computers in AD who cannot be pinged ($($script:cannotping.Count))"
#$script:cannotping
#' '

msg "List of computer in AD who cannot be managed ($($script:cannotmanage.Count))"
$script:cannotmanage
' '

msg "Warning messages ($($script:warningmsg.Count))"
$script:warningmsg
' '

msg "Full list of routing commands ($($script:commands.Count))"
$script:commands
' '

msg 'Began at' $start
msg 'Done at' (get-date).DateTime.ToString()

 

Enumerating IP Addresses on Network Adapters using PowerShell

Regardless of whether a server is for Exchange, for SQL, or for any other use; a key component of the server’s configuration is the set of IP addresses assigned to it.

Many organizations apply all addresses (even server addresses) using DHCP. For servers, this is often based on reservations of the MAC addresses on those servers. In most cases, this works well. However, if the DHCP server(s) should be unavailable (for whatever reason), the server will not receive the desired address, and instead will receive an APIPA address (that is, an IPv4 address starting with “169.” as the first octet of the IPv4 address).

Regardless of the result, for many servers it is important to know if the IP addresses should change. The first step in that process is to be able to enumerate (list) all of the IP addresses for all of the network interfaces on the server.

There are a number of mechanisms available for obtaining this information from Windows; including but not limited to “ipconfig.exe”, WMI, “wmic.exe”, “netsh.exe”, and others. The challenge for using most of the available interfaces is that they provide a significant amount of extraneous information. Extraneous information makes the output very difficult to parse and use within scripts.

This blog post provides a script that enumerates all of the network interfaces available on a particular computer and the associated IP addresses. The second script, which you could schedule to run every 15-30 minutes, compares and contrasts any changes in IP addresses on a server and reports the change via a SMTP server (such as Exchange Server).

The first script:

 

###
### IP-Address-Check.ps1
###
### This script lists all Ethernet adapters supporting IP on a computer and
### the associated IP addresses - both IPv4 and IPv6. A simple object is
### output containing the name of the interface, an array containing the IPv4
### addresses, and an array containing the IPv6 addresses.
###
### While this information is available from netsh.exe, the format of the
### output from netsh.exe is not conducive for easy re-use or parsing.
###
### Michael B. Smith
### michael at smithcons dot com
### http://essential.exchange
### February 28, 2012
###

Set-StrictMode -Version 2.0

$HKLM = 2147483650
$wmi  = [wmiclass]"\root\default:StdRegProv"

function RegRead
{
	Param(
		[int64] $hive,
		[string]$keyName,
		[string]$valueName,
		[ref]   $value,
		[string]$type = "REG_SZ"
	)

	switch ( $type )
	{
		'reg_sz'
			{
				$r = $wmi.GetStringValue( $hive, $keyName, $valueName )
				$value.Value = $r.sValue
			}
		'reg_dword'
			{
				$r = $wmi.GetDWORDValue( $hive, $keyName, $valueName )
				$value.Value = $r.uValue
			}
		'reg_qword'
			{
				$r = $wmi.GetQWORDValue( $hive, $keyName, $valueName )
				$value.Value = $r.uValue
			}
		'reg_binary'
			{
				$r = $wmi.GetBinaryValue( $hive, $keyName, $valueName )
				$value.Value = $r.uValue
			}
		default
			{
				write-error "ERROR: RegRead $hive $keyName $valueName"
				return 1
			}
	}

	return $r.ReturnValue
}

function EnumerateAdapters
{
	$nicSettings = gwmi Win32_NetworkAdapterSetting -EA 0
	foreach( $nicSetting in $nicSettings )
	{
		$nicElement = [wmi] $nicSetting.Element
		if( $nicElement.AdapterType -eq "Ethernet 802.3" )
		{
			$nicConfig = [wmi] $nicSetting.Setting ## is of type Win32_NetworkAdapterConfiguration
			$nicGUID = $nicConfig.SettingID
			if( $nicConfig.IPEnabled -eq $true )
			{
				$hive = $HKLM
				$keyName = "System\CurrentControlSet\Control\Network\" +
					"{4D36E972-E325-11CE-BFC1-08002BE10318}\" + 
					$nicGUID + 
					"\Connection"
				$valueName = "Name"

				$name = ''
				$result = RegRead $hive $keyName $valueName ( [ref] $name ) 'reg_sz'
				if( $result -ne 0 )
				{
					$name = ""
				}

				$arrIPListPublic_v6 = @()
				$arrIPListPublic_v4 = @()

				foreach( $ip in $nicConfig.IPAddress )
				{
					if( $ip.IndexOf( ':' ) -ge 0 )
					{
						$arrIPListPublic_v6 += $ip
					}
					else
					{
						$arrIPListPublic_v4 += $ip
					}
				}

				$obj = "" | select Name, IPv4Addresses, IPv6Addresses
				$obj.Name = $name
				$obj.IPv4Addresses = $arrIPListPublic_v4
				$obj.IPv6Addresses = $arrIPListPublic_v6

				$obj  ### output the object to the pipeline

				$arrIPListPublic_v4 = $null
				$arrIPListPublic_v6 = $null
			}

			$nicConfig = $null
		}
		$nicElement = $null
	}
	$nicSettings = $null
}

###
### Main
###

EnumerateAdapters

 

The second script:

 

###
### IP-Check-Controller.ps1
###
### Check to see if any IP addresses on a computer have changed. This may 
### be relevant in many configurations based on DHCP.
###
### Michael B. Smith
### michael at smithcons dot com
### http://essential.exchange
### February 28, 2012
###

Param(
	[string]$to  = "ip-report@example.com",
	[string]$mx  = "mx.example.com",
	[string]$sub = "The IP address information has changed at $($env:ComputerName)",
	[string]$fr  = "ip-check-controller@example.local"
)

[string]$nl = "`r`n"

###
### Main
###

if( ( Test-Path "Addr-old.txt" -PathType Leaf ) )
{
	rm "Addr-old.txt"
}
if( ( Test-Path "Addr-new.txt" -PathType Leaf ) )
{
	mv "Addr-new.txt" "Addr-old.txt"
}

.\IP-Address-Check | out-file "Addr-new.txt"

$result = Compare-Object -ReferenceObject $(gc "Addr-old.txt") -DifferenceObject $(gc "Addr-new.txt") -PassThru
if( $result -eq $null )
{
	## no changes to file
	exit
}

### if we get here, the files are different

$text =
	"A change has occurred in the IP addresses or active adapters.$nl$nl"+
	"The changes found are:$nl"

foreach( $line in $result )
{
	$text += "`t" + $line + $nl
}

$text += $nl + "The new full configuration is:$nl"
	$lines = gc "Addr-New.txt"
	foreach( $line in $lines )
	{
		$text += "`t$line$nl"
	}

$text += $nl + "The old full configuration is:$nl"
	$lines = gc "Addr-Old.txt"
	foreach( $line in $lines )
	{
		$text += "`t$line$nl"
	}

Send-MailMessage -To $to -Subject $sub -From $fr -Body $text -SmtpServer $mx -Priority High

 

Typically, instead of scheduling the second PowerShell script, you would schedule a BAT script, as shown below:

 

@echo off
REM
REM IP-Check-Controller.bat
REM
REM Michael B. Smith
REM michael at smithcons dot com
REM http://essential.exchange
REM February 28, 2012
REM

powershell.exe -command ".\IP-Check-Controller.ps1"

 

Until next time…

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

 


Follow me on twitter: @EssentialExch

Creating Explicit Credentials in PowerShell for WMI, Exchange, Lync, Remoting, etc.

When creating PowerShell cmdlets for any Microsoft technology – WMI, Exchange, Lync, etc. – it is common to need to provide credentials that are different from the default credentials. This can be even more important when you are using PowerShell remoting to connect to a remote computer.

However, using the built-in cmdlet Get-Credential causes a dialog box to be opened on the console! (And it will simply fail in some cases, when the internal PowerShell $host.UI.PromptForCredential interface has not been implemented.) This is certainly not something that you want to happen when your PowerShell script is being called with remote PowerShell or from a service, or in many other scenarios.

The solution is to pass in the full credential, already containing the secure password and the user names and (optionally) the domain or a user principal name. This is a bit challenging, as the constructor for a secure string doesn’t provide you an option for passing in an entire password. Therefore, you must build the secure string one character at a time.

The two functions below make the process easy.

Note: the $username parameter to newPSCredential can be in several formats: a plain username, a domain\username, or username@domain.com, or computername\username (for a local user).

Note 2: some functions want a NetworkCredential instead of a PSCredential. Creating one of those is as simple as changing System.Management.Automation.PSCredential to System.Net.NetworkCredential.

Note 3: as a security best practice, after you call the newPSCredential function, you should ensure that the plain text password is no longer available in the calling routine.

Enjoy!

function newSecurePassword( [string]$password )
{
        ###
        ### newSecurePassword
        ###
        ### Take the normal string password provided and turn it into a 
        ### secure string that can be used to set credentials.
        ###

        $secure = new-object System.Security.SecureString

        $password.ToCharArray() |% { $secure.AppendChar( $_ ) }

        return $secure
}

function newPSCredential( [string]$username, [string]$password )
{
	###
	### newPSCredential
	###
	### Create a new PSCredential object containing the provided
	### username and plain-text password.
	###
        $pass = newSecurePassword $password

        $cred = new-object System.Management.Automation.PSCredential( $username, $pass )

        $cred
}

 

Until next time…

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


Follow me on twitter! : @EssentialExch

Generating a report on Distribution Groups and their Membership, v2

In August of 2010, I posted Generating a report on Distribution Groups and their Membership. For most people, that script worked just fine.

However, it had some issues:

  • Large groups would cause PowerShell to generate an error about concurrent pipelines
  • The script generated string output instead of object output

This new version fixes those issues and adds ‘help’ content for the script. The script is below, but the information about the reasoning is copied directly from the original post, modified appropriately.

A common request is to get a list of all distribution groups and the members contained in that distribution group.

Note: a distribution group may also be a security group. From an Exchange Server perspective, the important thing is whether the group is mail-enabled or not.

You can take this report and pipe it to out-file in order to save the output to a disk file. Then you can inspect the file later, email it, copy-n-paste it, whatever you want. Export-Csv and Export-CliXml are also good options for exporting this data, especially since there is the potential for the contents of several arrays to be output.

Here is the script:

##
## Report-DistributionGroupsAndMembers.ps1
## v2.0
##
## Michael B. Smith
## http://TheEssentialExchange.com
## August, 2010
## July, 2011
##
## Requires the Exchange Management Shell
## As of version 2.0, requires PowerShell 2.0
## Tested on both Exchange 2007 and Exchange 2010
##

#requires -Version 2.0

if( $args )
{
	if( ( $args.Length -eq 1 ) -and
	    ( ( $args[0] -eq "-?" ) -or
	      ( $args[0] -eq "-help" ) ) )
	{
		@"

NAME
	Report-DistributionGroupsAndMembers

SYNOPSIS
	This script outputs information about all distribution groups. The 
	information includes:

	GroupName    - The name of the distribution group
	Identity     - The unique identity of the group (an X400 identifier)
	ManagerNames - An array containing the names of the managers for the
		group. On Exchange 2007, this will contain a maximum of one
		entry. On Exchange 2010, there may be many entries. It is
		also possible (and quite likely in some environments), for
		this array to be empty.
	ManagerCanonicalNames - An array containing the canonical names
		(also known as the relative distinguished name) for the
		managers of this group. It will match, index by index, the
		contents of ManagerNames.
	Members      - An array containing the names of all the members of
		this group. It is also possible for this array to be empty.

	This script must be executed from within an Exchange Management Shell. 

SYNTAX
	Report-DistributionGroupsAndMembers [-help]

"@ 		| out-default

		return
	}

	throw "No parameters are allowed for this script"
}

$distributionGroups = Get-DistributionGroup -ResultSize Unlimited

foreach( $distributionGroup in $distributionGroups )
{
	## not all of these temporaries are necessary, but it
	## simplifies understanding the PowerShell code

	$groupName  = $distributionGroup.Name
	$groupID    = $distributionGroup.Identity

	$managedBy  = $distributionGroup.ManagedBy
	$mgrName    = @()
	$mgrCName   = @()

	if( $managedBy -is [Microsoft.Exchange.Data.Directory.ADObjectId] )
	{
		$mgrName  += $managedBy.Name
		$mgrCName += $managedBy.RDN.ToString().SubString(3)
	}
	elseif( $managedBy.Count -gt 0 )
	{
		foreach( $manager in $managedBy ) 
		{
			$mgrName  += $manager.Name
			$mgrCName += $manager.RDN.ToString().SubString(3)
		}
	}

	$membersArray = @()

	$members = Get-DistributionGroupMember -Identity $groupID -ResultSize Unlimited
	foreach( $member in $members )
	{
		$membersArray += $member.Name
	}

	$members = $null

	$hash = @{
		GroupName		= $groupName
		Identity		= $groupID
		ManagerNames		= $mgrName
		ManagerCanonicalNames	= $mgrCName
		Members			= $membersArray
	}

	New-Object PSObject -Property $hash	## inject to the pipeline
}

$distributionGroups = $null

 

Until next time…

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


Follow me on twitter! : @EssentialExch

Black Hole Distribution Groups

I had the question posed to me today: if I have a mail-enabled group (either a security group or a distribution group) that has no members, and it receives an email, why don’t I get an NDR?

Well – works as intended!

Let’s have a thought experiment considering how mail-enabled groups work (from an Exchange perspective):

  1. Create a distribution group
  2. Assign it one or more email addresses
  3. Don’t add any members
  4. Send an email
  5. Let Transport expand the group
  6. For every member in the group, make a copy of the email
  7. Stop

What’s different about the empty group? Absolutely nothing. A copy of the email is made for every member of the group – it just so happens that there aren’t any members of the group!

Why would you do this? It’s commonly done for employees that have left a company. For some period of time, you may want an ex-employees supervisor or manager to receive their emails. But eventually, you just want them to “go away”.

It’s also commonly done for “temporary” email addresses. For example, your company decides to run a promotion, and your have your customers send an email to a custom temporary email address. When the promotion is done, black-hole the email.

Now, starting in Exchange 2007 you can also create custom responses with transport rules, if you need or want them.

Black hole distribution groups have worked this way since at least Exchange 5.5. A further note: it’s also common to hide these type of mail-enabled groups from the Exchange address book, so that they are not present in the GAL. Also be aware that you can have dozens of addresses assigned to a single group; so in most instances you’ll only need a single black hole distribution group in your organization.

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!


Follow me on twitter! : @EssentialExch

Exchange 2003 FE Servers vs. Server 2008 Active Directory

I spent eight hours over the last two days figuring out an interesting – but weird – problem. Once I figured out the problem, correcting it was a simple matter.

I’ll just give you the problem description and then the solution. Hopefully it will save you more than a little time in the future.

I have a client (one of several in this particular situation) who has an Exchange 2003 Front-End server located in their DMZ. Yes, that’s right, their DMZ. In the “long-ago time”, this was considered to be a favored practice by Microsoft. That, of course, has changed over the years. Now, in 2011, we do not want any domain member servers located in the DMZ. Why is that? Because to install a domain member in a DMZ basically means that you have to make “swiss cheese” out of your firewall. And, effectively, if a DMZ server is compromised it means that your entire Active Directory can be compromised. The entire list of potentially affected ports is shown in KB 832017, and at the end of the day – it basically says that you have to open everything above port 1024 to make it all work.

With all that being said, if you are using Exchange 2003 with Server 2003 Active Directory (by which I mean an Active Directory domain controller hosted on a Windows Server 2003 server), you could get by with a much more limited set of ports (although it still isn’t small!):

DNS (TCP and UDP 53)
Kerberos (TCP and UDP 88)
RPC Endpoint Mapper (TCP 135)
NetBIOS Name Service (TCP 137)
NetBIOS Datagram Service (TCP 138)
NetBIOS Session Service (TCP 139)
LDAP (TCP and UDP 389)
Directory Services (TCP 445)
LDAP Global Catalog (TCP 3268)
Remote Desktop Protocol (TCP 3389)
Active Directory RPC End-Point (AD-RPC-EP)

You should notice that all of these have defined ports except for the last! By definition, the AD-RPC-EP is a random high port.

However, a somewhat surprising fact is that when you run Active Directory on Windows Server 2003 (in other words, you have a domain controller on Server 2003), the AD-RPC-EP is always either port 1025 or 1026!

Starting with Server 2008, this is no longer true. “Port randomization” ensures that ports are allocated at truly random locations.

So… I have a particular client who, as part of their Exchange 2003 to Exchange 2010 upgrade effort decided that they first wanted to upgrade their Active Directory. That was fine by me – there are no documented restrictions regarding the operating system level of domain controllers to be used by Exchange 2003.

The day we changed the last domain controller from Windows Server 2003 to Windows Server 2008 R2, the Exchange FE server stopped working. Oh, $%&#.

Thankfully, the FE server was only being used for Outlook Web Access (OWA). SMTP was injected into the Exchange environment via a Barracuda cluster directly into the internal back-end server environment.

I’m rather hardheaded. So I wanted to figure this out. And, quite frankly, it took awhile. Eventually, it took an examination using portqry and rpcping (you can find out lots of information about these utilities by using Google or Bing and searching for “portqry site:support.microsoft.com” and “rpcping site:support.microsoft.com”). Comparing the results of those to the “access control lists” from the firewall showed me that the firewall always expected a port to be open at TCP 1025 and/or TCP 1026. Neither of these ports were open on Server 2008 R2!

I went back and investigate some other customers who were running Active Directory on Server 2003. On every single one of their servers, the process lsass.exe had either TCP 1025 or TCP 1026 (or both) open.

A google here, a bing there, and I was led to Active Directory Replication Over Firewalls and KB 224196: Restricting Active Directory replication traffic and client RPC traffic to a specific port.

These led me to understand that on Server 2008 and above AD-RPC-EP could happen at any random port – but that there is a way to specify the port that will be used. YAY!

For the following

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Registry value: TCP/IP Port
Value type: REG_DWORD
Value data: (available port)

specifying a “value data” of either 1025 or 1026 ensures that Server 2008 and Server 2008 R2 operate as did Server 2003. After setting this value, it does take a reboot of the affected DC/server for the value to take effect.

Once this was done, my client was happy again! I hope this helps you in your migrations…

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!


Follow me on twitter! : @EssentialExch

Finding Disk Space Used By Exchange, v2

Long ago and far away (way back in 2006) I wrote an article for finding the disk space used by Exchange 2000 and Exchange 2003, Finding disk space used by Exchange. While this worked through a few Exchange 2007 betas, by Exchange 2007 RTM, the STM file had been removed, and the original script would bomb, making the script only useful for Exchange 2000 and Exchange 2003.

Astute VBscript users would determine how to comment out the few lines causing the issue, but for most folks, that was too much.

So, I finally updated that script for Exchange 2007 and Exchange 2010 (tested on both) and updated it to PowerShell.

This is the script:

function build-object( [string]$server, [string]$edbfilepath, [string]$displayName )
{
	write-debug "build-object enter"
	write-debug "build-object server: $server"
	write-debug "build-object edbfilepath: $edbfilepath type $($edbfilepath.gettype().ToString())"
	write-debug "build-object displayName: $displayName"
	write-debug " "

	$o = "" | Select Name, Display, Length
	$o.display = $displayName

#	if( $server -eq $env:ComputerName )
	if( 0 )
	{
		$r = dir -ea 0 $EdbFilePath
	}
	else
	{
		$filename = "\\" + $server + "\" + $edbfilepath.SubString( 0, 1 ) + 
			"$" + $edbfilepath.SubString( 2 )
		write-debug "Calculated filename: $filename"
		$r = dir -ea 0 $filename
	}

	$o.Name = $r.Name
	$o.Length = $r.Length

	write-debug "build-object exit"
	return $o
}

Get-Command Get-ExchangeServer -ea 0 | out-null
if( ! $? )
{
	write-error "You must run this script within an Exchange Management Shell"
	return
}

$legacy = Get-ExchangeServer $env:Computername -ea 0
if( ! $? )
{
	write-error "You must run this script on an Exchange server"
	return
}

$org = $legacy.ExchangeLegacyDN.SubString( 3 )
$org = $org.SubString( 0, $org.IndexOf( '/' ))
"Exchange Organization Name: $org"

$default = ( Get-AcceptedDomain |? { $_.Default -eq $true } ).DomainName
"Default SMTP Domain: $default"

$forest = $legacy.DistinguishedName.SubString( $legacy.DistinguishedName.IndexOf( 'DC=' ) )
"Active Directory Forest: $forest"
" "
"All Exchange Servers in forest"
$servers = Get-ExchangeServer | select Name
foreach( $server in $servers )
{
	"`tName: $($server.Name)"
}
" "
"All Mailbox Servers in forest"
$mailbox = Get-ExchangeServer |? { $_.ServerRole -match "Mailbox" } | Select Name, IsMemberOfCluster
foreach( $server in $mailbox )
{
	"`tName: $($server.Name)"
}
" "

"Acquiring size of databases..."
" "
[int64]$totalSize = 0
foreach( $server in $mailbox )
{
	"Server name: $($server.Name)"

	[int64]$serverSize = 0
	$serverArray = @()

	if( $server.IsMemberOfCluster -eq 'Yes' )
	{
		$mailboxServer = Get-MailboxServer $server.Name -ea 0
		$myServer = $mailboxServer.RedundantMachines[0]

		$serverArray += (get-mailboxdatabase      -server $server.Name -ea 0) |% {
			build-object $myServer $_.EdbFilePath $_.AdminDisplayName;
		}

	}
	else
	{
		$serverArray += (get-mailboxdatabase      -server $server.Name -ea 0) |% {
			build-object $_.Server $_.EdbFilePath $_.AdminDisplayName;
		}
	}

	$serverArray += (get-publicfolderdatabase -server $server.Name -ea 0) |% {
		build-object $_.Server $_.EdbFilePath $_.AdminDisplayName;
	}

	$serverArray |% { $serverSize += $_.Length }

	foreach( $element in $serverArray )
	{
		if( $element )
		{
			"`tDatabase name: $($element.Display)"
			"`t`tEDB File: $($element.Name)"
			"`t`tEDB size: {0} bytes, {1} GB" -f $element.Length.ToString("N0"), ($element.Length / 1GB).ToString("N3")
			#$element
		}
	}
	"Total size of databases on server {0} bytes, {1} GB" -f  $serverSize.ToString("N0"), ($serverSize / 1GB).ToString("N3")
	" "
	$totalSize += $serverSize
}

"Total size of all databases in organization {0} bytes, {1} GB" -f  $totalSize.ToString("N0"), ($totalSize / 1GB).ToString("N3")

 

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!


Follow me on twitter! : @EssentialExch

More on Active Directory Privileged Groups and Exchange Server

In October of 2008, I wrote the article adminCount, adminSDHolder, SDProp and you! This article discussed why membership in privileged groups could cause permissions challenges. You may want to refer to it before proceeding.

With Exchange Server 2010, the overall situation has continued to get more restrictive. Exchange Server 2010 needs for users who have mailboxes to inherit permissions in order for Role-Based Access Control (RBAC) and overall Exchange access to work properly. Membership in a privileged group will stop a mailbox from inheriting permissions. Usually, normal mailbox access will work fine (i.e., using Outlook with MAPI) due to historical permissions present on a mailbox, but any other IIS based or MAPI service will fail. This includes, but is not limited to, Blackberry Enterprise Server, Exchange ActiveSync, Outlook Web App, etc.

You can see a complex way of working around this issue described in KB Article 907434: The “Send As” right is removed from a user object after you configure the “Send As” right in the Active Directory Users and Computers snap-in in Exchange Server.But that method is an administrative nightmare.

Realistically speaking – what can you do?

The answer is simple: Get your users out of privileged groups.

No user who is Administrator, a Domain Admin, an Enterprise Admin, or a Schema Admin should be signing into Exchange with an account that is a member of those groups. This is also true for any member of the Built-in\Administrators group that exists on Domain Controllers. Every user who has access to a high-privilege account should also have a normal user account that they use for day-to-day usage – just like everyone else.

For the other privileged groups (Account Operators, Server Operators, Print Operators, Backup Operators, Cert Publishers) – these are legacy groups. They are a carry-over from Windows NT. Don’t use them. Instead, use a computer’s Local Security Policy – or a Domain Security Policy when appropriate – to assign users who need those capabilities the specific rights they require.

Usually, you will find that the built-in groups provide more power than you think they do (e.g., a member of Account Operators, Server Operators, Print Operators, or Backup Operators can log in locally to a domain controller and shut it down). Mapping between the groups is fairly simple by examing User Rights Assignments in any Local Security Policy. An online version of this is available at: http://technet.microsoft.com/en-us/library/bb726980.aspx in tables 7-7, 7-8, and 7-9.

You may not normally consider <insert-any-group-name-here> to be a privileged group. But Active Directory does. Get users out of privileged groups where possible, and where not possible – assign (and require use of!) users a normal account and a privileged account.

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!


Follow me on twitter! : @EssentialExch

Moving a Mailbox Database Path

In Exchange 2007 and Exchange 2010, added functionality in Move-Mailbox (and New-MoveRequest), along with the support of online mailbox moves, have reduced the requirement of moving entire databases around very much (it’s easier to just move all the mailboxes in the mailbox database to a new mailbox database in the proper location).

But sometimes – you just need to do it. Even with the downtime it may cause.

You CAN do it from the Exchange Management Console or from the Exchange Management Shell. However, the provided status information is worthless. You have no idea how far along the data movement is. What I recommend instead is this process:

  1. Dismount the mailbox database
  2. Use ROBOCOPY to copy the database file from the old location to the new location
  3. Use Move-DatabasePath -ConfigurationOnly to update Exchange with the new location of the database
  4. Mount the mailbox database

In pseudo-PowerShell:

  1. dismount-database <dbname>
  2. robocopy <src-dir> <dest-dir> <dbname>.edb
  3. move-DatabasePath -Id <dbname> -ConfigurationOnly -EDBFilePath <new-full-path-to-edb>
  4. mount-database <dbname>

ROBOCOPY provides excellent information as to the status of a filecopy.

Also note that “ESEUTIL /y” is a good solution for copying large files as well. It provides respectable filecopy status information.

Until next time…

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

Edit November 22, 2010 – I’m extremely embarassed. In the original version of this post I used “unmount-database” (which doesn’t exist, of course) instead of “dismount-database”. Thankfully, only a few dozen people pointed out my error to me.


Follow me on twitter! : @EssentialExch