PowerShell Quick Script: Finding the Exchange Schema Version

Every major Exchange release comes with updates to the Active Directory schema. In this case, "major release" means new major version (at RTM), every service pack, and (probably) every Cumulative Update with the new servicing model introduced for Exchange 2013.

Each update is unique to that particular release and, in general, they are cumulative. A notable exception to this was when Exchange Server 2007 SP3 had a higher schema version than that of Exchange Server 2010 RTM.

Over the lifetime of modern Exchange (since the integration to Active Directory with Exchange 2000), there have been a number of issues making it important to know the current schema version of Exchange. Most instructions on the web suggest using ADSIEdit to examine the relevant variable and value.

However, that is potentially risky (because ADSIEdit can be a dangerous tool) and can be a little confusing to use.

Here is a quick little PowerShell script to report on the proper value:

$root = [ADSI]"LDAP://RootDSE"
$name = "CN=ms-Exch-Schema-Version-Pt," + $root.schemaNamingContext
$value = [ADSI]( "LDAP://" + $name )
"Exchange Schema Version = $( $value.rangeUpper )"

The ms-Exch-Schema-Version-Pt attribute is never assigned to a class in the schema, it is used exclusively to identify the value of the Exchange Schema Version.

To anyone who has used ADSI in PowerShell or VBScript before, the little four-line script will appear very familiar. The PowerShell ADSI accelerator syntax allows for the corresponding PowerShell script to be shorter than the equivalent VBScript script.

In order for this script to work, it must be executed on a computer joined to an Active Directory domain. The execution context for the script (that is, the user account) requires no special privileges.

Oh, and if you prefer PowerShell one-liners, here is the same script as a one-liner for you:

"Exchange Schema Version = " + ([ADSI]("LDAP://CN=ms-Exch-Schema-Version-Pt," + ([ADSI]"LDAP://RootDSE").schemaNamingContext)).rangeUpper

Follow me on Twitter @essentialexch

 

PowerShell Quick Script: Invoke-Splat

One of the features added to PowerShell v2 (and of course continued with PowerShell v3) is splatting. Without going into extreme detail (there are plenty of other blogs and books that do that), splatting allows you to pass parameters to a PowerShell cmdlet via an associative array (that is a fancy name for a hash table).

The hash table contains the parameter name as a key and the parameter's value as a value. The hash table contains two matched arrays, the keys array and the values array. For example, if a hash table contains three values, then accessing $hash.keys[ 1 ] will provide the name of a given hash entry and $hash.values[ 1 ] will provide the corresponding value for that entry.

The big deal behind splatting is that it allows you to easily construct custom parameter lists that get passed to cmdlets based on the special needs of a calling script. That sounds dense. 🙂 But it is a good thing. For example, if you want to call a cmdlet with different parameters based on the time of day, or on a particular computer, or whether your script was started with a switch parameter, or whether a particular string parameter has a value – then splatting is for you.

Splatting has a somewhat hidden advantage. Switch parameters require special handling under normal circumstances. With splatting, no special handling is required. You set a switch to $true or $false, without using special spacing and/or a colon.

I use splatting extensively in scripts I have developed since PowerShell v2 was released. Today, my friend Carl Webster, the Accidental Citrix Admin, asked about a way to simplify calling cmdlets in certain of his scripts. My answer was "use splatting". After a couple of back-and-forth emails, about the best way to use splatting, I concluded that the easiest thing to do was to generalize a routine to provide splatting for a cmdlet and pass that over to Carl.

After further thought and evolution on the basic concept of the routine I sent to Carl, I decided it could be a great deal more powerful (get it – powerful vs. PowerShell? HAHAHAHA) if I added in some logging capabilities and provided for the suppression of empty parameters. Thus was born Invoke-Splat. I have already taken Invoke-Splat and used it to simplify several of my own scripts.

Invoke-Splat takes the cmdlet to invoke as a parameter, plus all of the parameters for that cmdlet, as "parameter value" pairs, plus a couple of optional switch parameters to control Invoke-Splat itself. Invoke-Splat is dependent on PowerShell's named parameter matching, combined with positional parameter matching, and that everything that does not meet either of those, is stored in the special argument $args.

The splatNotEmpty switch ensures that parameters whose values evaluate as either null or empty strings are not passed as parameters to the called cmdlet. This is especially important for parameters that cannot normally be null or empty!

The splatDebug switch causes the cmdlet and each of the "parameter value" pairs to be output to the calling host.

The splatCmdlet string parameter is (obviously) the name of the cmdlet that will be executed with the other parameters.

Note that the other parameters may be empty!

For example:

Invoke-Splat Get-Process ID $PID FileVersionInfo $false -splatDebug

and

Invoke-Splat Get-Process ID $PID Name '' -splatDebug -splatNotEmpty

Without further ado, here is Invoke-Splat.

function Invoke-Splat
{
	Param(
		[string]$splatCmdlet,
		[switch]$splatNotEmpty,
		[switch]$splatDebug
	)

	## $args[ 0 .. n ] are matching "parameter argument" pairs

	$splats = @{}
	for( $i = 0; $i –lt $args.Length; $i = $i + 2 )
	{
		if( $splatNotEmpty )
		{
			## don’t pass arguments with empty strings
			if( ( $args[ $i + 1 ] –as [string] ).Length –gt 0 )  
			{
				$splats.$( $args[ $i ] ) = $args[ $i + 1 ]
			}
		}
		else
		{
			$splats.$( $args[ $i ] ) = $args[ $i + 1 ]
		}
	}
	if( $splatDebug )
	{
		write-host -ForeGroundColor Yellow "DEBUG: Invoke-Splat: cmdlet = $splatCmdlet"
		foreach( $entry in $splats.Keys )
		{
			write-host -ForeGroundColor Yellow "DEBUG: Invoke-Splat: entry: $entry = $($splats.$entry)"
		}
	}

	& $splatCmdlet @splats
}

Please follow me on Twitter: @essentialexch.

Thanks for your visit!

 

Windows Management Framework 3.0 / PowerShell 3.0 and Exchange

In the last few days, Windows Management Framework 3.0 (WMF 3.0) has begun appearing in Microsoft Update (MU), Windows Update (WU), Windows Software Update Services (WSUS), and on Configuration Manager Software Update Points. This basically means that Microsoft is now suggesting that WMF 3.0 be installed on all of your servers where the update is applicable.

This update is released as KB 2506146 and KB 2506143.

DON'T DO IT.

WMF 3.0 includes PowerShell 3.0.

PowerShell 3.0 is a great improvement to PowerShell. No question about it.

However, Exchange 2010 is NOT currently qualified to work with PowerShell 3.0. And, in fact, it doesn't. It will break. PowerShell 3.0 compatibility will come with Exchange 2010 Service Pack 3, due sometime in the first half of calendar year 2013 (word on the street says first quarter).

If you have installed WMF 3.0, you will also find that Exchange Update Rollups will fail to install.

Exchange 2007 is also not qualified to work with PowerShell 3.0. And, as far as I know, never will be.

You absolutely, positively, do not want to install the update on your Exchange servers.

You also do not want to install the update on workstations or utility servers where you have Exchange Management Tools installed.

I have also heard reports that SharePoint 2010 also has problems with the WMF 3.0 release. I can believe it. You should avoid that as well.

Good luck!

P.S. Exchange 2013 does work with WMF 3.0 and in fact, WMF 3.0 is required to install Exchange 2013. If you are one of the rare few running Exchange 2013, you do not need to be concerned about this.

 

Microsoft Security Advisory 2737111 – Exchange 2007/2010/2013

Well, in case you haven’t seen it, an Exchange Security advisory was released today.

“Vulnerabilities in Microsoft Exchange and FAST Search Server 2010 for SharePoint Parsing Could Allow Remote Code Execution”

http://technet.microsoft.com/en-us/security/advisory/2737111

And yes, it also affects the Exchange 2013 Preview.

It wasn’t immediately obvious to me, but every Exchange CAS/CAFE has these libraries installed. Microsoft licenses them from Oracle.

I’m guessing that that will change the workaround to:

Get-OwaVirtualDirectory |? {
$_.OwaVersion -eq ‘Exchange2007’ -or $_.OwaVersion -eq ‘Exchange2010’ –or $_.OwaVersion –eq ‘Exchange2013’ } |
Set-OwaVirtualDirectory -WebReadyDocumentViewingOnPublicComputersEnabled:$False `
-WebReadyDocumentViewingOnPrivateComputersEnabled:$False

But I’m on the road and don’t have access to my E15 test lab at the moment…

Thanks to Susan Bradley, the SBS Diva, for pointing out to me that this doesn’t require third party add-ins.

[Edit]

More information:

“In Microsoft Exchange Server 2007 and Exchange Server 2010, Outlook Web App (OWA) users are provided with a feature called WebReady Document Viewing that allows users to view certain attachments as a web page instead of relying on local applications to open/view it. Oracle Outside In is used by the conversion process in the server backend to support the WebReady feature. Microsoft licenses this library from Oracle.”

In the Exchange Server 2007/2010 scenario, the conversion process that uses Oracle Outside In, TranscodingService.exe, runs as LocalService.

http://blogs.technet.com/b/srd/archive/2012/07/24/more-information-on-security-advisory-2737111.aspx

 

Bit Shifting in PowerShell, Redux

I do bit shifting in PowerShell all the time. It's quite necessary when you are working with option values in Active Directory, WMI, and various Win32 interfaces. .NET tends to use enumerations, which are tad easier to deal with in PowerShell.

I had never felt it necessary to break my routines out before, but I saw a posting on this topic by another individual today and I just thought he was making it harder than it had to be. I wanted to present another option to the community for these types of routines. I'm not putting down his work in any way – it was quite ingenious. I never would've thought of doing it that way.

Just FYI, 'shr' is an abbreviation for 'shift right' and correspondingly 'shl' is an abbreviation for 'shift left'. When I was in college (in the stone age) those function names were used in "Pascal extension libraries" and in "Fortran libraries" for performing shift operations. Shift operations are built-in as native operations to many (most?) compiled languages such as C and its various dialects.

Enjoy.


###
### Bit-shift operations
### bit-shift.ps1
###
### for bytes and short integers
###
### Michael B. Smith
### michael at TheEssentialExchange.com
### May, 2012
###

$bitsPerByte = 8	## [byte]
$bitsperWord = 16	## [int16] or [uint16]

function shift-left( [int]$valuesize, [int]$mask, $val, [int]$bits )
{
	if( $bits -ge $valuesize )
	{
		return 0
	}
	if( $bits -eq 0 )
	{
		return $val
	}
	if( $bits -lt 0 )
	{
		write-error "Can't shift by a negative value of bits"
		return -1
	}

	### it's possible to write this so that you never
	### overshift and generate an overflow. it's easier
	### to use a larger variable and mask at the end.

	[int]$result = $val
	for( $i = 0; $i -lt $bits; $i++ )
	{
		$result *= 2
	}

	return ( $result -band $mask )
}

function shift-right( [int]$valuesize, [int]$mask, $val, [int]$bits )
{
	if( $bits -ge $valuesize )
	{
		return 0
	}
	if( $bits -eq 0 )
	{
		return $val
	}
	if( $bits -lt 0 )
	{
		write-error "Can't shift by a negative value of bits"
		return -1
	}

	for( $i = 0; $i -lt $bits; $i++ )
	{
		## normally PowerShell does banker's rounding (well, .NET does)
		## we have to override that here to get true integer division.
		$val = [Math]::Floor( $val / 2 )
	}

	return $val
}

function shl-byte( [byte]$val, [int]$bits )
{
	$result = shift-left $bitsPerByte 0xff $val $bits
	if( $result -lt 0 )
	{
		return $result
	}

	return ( [byte]$result )
}

function shr-byte( [byte]$val, [int]$bits )
{
	$result = shift-right $bitsPerByte 0xff $val $bits
	if( $result -lt 0 )
	{
		return $result
	}

	return ( [byte]$result )
}

function shl-word( [uint16]$val, [int]$bits )
{
	$result = shift-left $bitsPerWord 0xffff $val $bits
	if( $result -lt 0 )
	{
		return $result
	}

	return ( [uint16]$result )
}

function shr-word( [uint16]$val, [int]$bits )
{
	$result = shift-right $bitsPerWord 0xffff $val $bits
	if( $result -lt 0 )
	{
		return $result
	}

	return ( [uint16]$result )
}

function shl( $val, [int]$bits )
{
	if( $val -is [byte] )
	{
		return ( shl-byte $val $bits )
	}
	elseif( $val -is [int16] )
	{
		return [int16]( shl-word $val $bits )
	}
	elseif( $val -is [uint16] )
	{
		return ( shl-word $val $bits )
	}
	elseif( ( $val -lt 65536 ) -and ( $val -ge 0 ) ) ### pretend it's uint16
	{
		return ( shl-word ( [uint16]$val ) $bits )
	}

	write-error "value is an invalid type"
	return -1
}

function shr( $val, [int]$bits )
{
	if( $val -is [byte] )
	{
		return ( shr-byte $val $bits )
	}
	elseif( $val -is [int16] )
	{
		return [int16]( shr-word $val $bits )
	}
	elseif( $val -is [uint16] )
	{
		return ( shr-word $val $bits )
	}
	elseif( ( $val -lt 65536 ) -and ( $val -ge 0 ) ) ### pretend it's uint16
	{
		return ( shr-word ( [uint16]$val ) $bits )
	}

	write-error "value is an invalid type"
	return -1
}

 

Processing Large and Embedded Groups in PowerShell

I'm working with a client that has – over an extended period of time – accumulated thousands of security groups, most of which are mail enabled for use by both Exchange and for setting rights on various objects.

Becasue they use embedded groups (that is, placing a group as a member of another group), they have a horrible time keeping straight who is actually a member of those groups.

Recently an unintentional disclosure at the client has caused them to desire to clean this mess up. 🙂

They found that many tools weren't robust enough to deal with their environment. Their groups may contain thousands of members and dozens of embedded groups. And sometimes, the groups are recursive (or nested). That is, GroupA includes GroupB, GroupB includes GroupC, and GroupC includes GroupA. Also, due to historial reasons, many of their users have non-standard primary group memberships and those needed to also be included as part of the evaluation process.

Note: be aware – most tools will only return 1,500 members for a group (1,000 if your FFL is Windows 2000 mixed or Windows 2000 native). This includes most tools from Microsoft (e.g., dsquery and dsgroup). Some of the tools that handle that properly will go into an infinite loop if there are nested groups. Since the primary group is stored differently than other group memberships, most tools simply ignore it (the RID of the group is stored in the primaryGroupId attribute of a user object, instead of using a memberOf backlink or the member attribute forward link from the group itself).

We were unable to find a tool (which doesn't mean one isn't out there!) that handled all of these issues properly.

So, I wrote one. In PowerShell.

Note that performance is not great when you are scanning nested groups. This is because it is necessary to evaluate every member to determine the type of the member – user, group, contact, etc. That adds significant additional processing overhead.

Each individual piece of this script is pretty obvious (except for the "range" processing required for looking at large group memberships). But after putting it all together, it's a thing of magic. 🙂

Enjoy!


###
### Get-GroupMember
###
### This function processes LARGE groups. Most normal utilities are limited
### to returning a maximum of 1,500 members for a group. To get all members
### of a group requires using a "ranged" member attribute. Few programs,
### including many from Microsoft, go to that much trouble. This one does.
###
### Also, retrieving membership from embedded groups, while avoiding the
### problems that can occur with group recursion, is something that many
### programs do not handle properly. This one does.
###
### Also, some programs do not handle empty groups properly (including the 
### example range program on MSDN from Microsoft). This one does.
###
### Also, some programs do not also check for the primaryGroupID membership, 
### and thus cannot return the membership of, for example, 'Domain Users'. 
### This one does.
###
### The ADSpath for each member of the group is written to the pipeline.
###
### Michael B. Smith
### michael at TheEssentialExchange dot come
### May, 2012
###
### Parameters:
###
###	-group 			The short name for the group. This is looked
###				up to find the distinguishedName of the group.
###
###	-ExpandEmbeddedGroups	Whether to recurse and get the membership of
###				groups contained within the parent group. If
###				this option is specified, all embedded groups
###				are scanned (including groups embedded within
###				groups embedded within groups,etc. etc.).
###
###	-Verbose		Display to the host function entry/exit and
###				status information.
###
###	-VeryVerbose		Display to the host the ADSpath of each member
###				of the group (as well as write it to the pipe).
###
###	-Statistics		Display to the host some basic statistics about
###				the query (number of users, number of embedded
###				groups, number of contacts).
###

Param(
	[string]$group	= (throw "group must be specified"),
	[switch]$ExpandEmbeddedGroups,
	[switch]$Statistics,
	[switch]$Verbose,
	[switch]$VeryVerbose
)

### for the Statistics option

$script:groupUsers    = 0
$script:groupGroups   = 0
$script:groupContacts = 0

function msg
{
	if( -not $Verbose )
	{
		return
	}

	$str = ''
	foreach( $arg in $args )
	{
		$str += $arg
	}
	write-host $str
}

function vmsg
{
	if( -not $VeryVerbose )
	{
		return
	}
	msg $args
}

function Get-PrimaryGroupID
{
	Param(
		[string]$indent,
		[string]$ADSpath
	)

	msg "${indent}Get-PrimaryGroupId: enter, ADSpath = $adspath"

	[string]$pgToken = 'primaryGroupToken'

	### format of argument: LDAP://CN=Domain Users,CN=Users,DC=smithcons,DC=local

	$groupDE  = New-Object System.DirectoryServices.DirectoryEntry( $ADSpath )
	$searcher = New-Object System.DirectoryServices.DirectorySearcher( $groupDE )
	$searcher.Filter = "(objectClass=*)"

	$searcher.PropertiesToLoad.Add( $pgToken ) | Out-Null

	$result = $searcher.FindOne()
	if( $result -ne $null )
	{
		if( $result.Properties.Contains( $pgToken ) -eq $true )
		{
			msg "${indent}Get-PrimaryGroupId: exit, token = $($result.Properties.primarygrouptoken)"

			return $result.Properties.primarygrouptoken
		}
	}

	msg "${indent}Get-PrimaryGroupId: exit, token not found"
	return 0
}

function Search-PrimaryGroupID
{
	Param(
		[string]$indent,
		[string]$namingContext,
		[int]$primaryGroup,
		[hashtable]$dictionary
	)

	msg "${indent}Search-PrimaryGroupId: enter, namingcontext = '$namingContext', primaryGroup = $primaryGroup"

	$ldapFilter = "(primaryGroupID=$primaryGroup)"

	$directorySearcher = New-Object System.DirectoryServices.DirectorySearcher
	$directorySearcher.PageSize    = 1000
	$directorySearcher.SearchRoot  = ( "LDAP://" + $namingContext )
	$directorySearcher.SearchScope = "subtree"
	$directorySearcher.Filter      = $ldapFilter

	### load the properties we want

	$directorySearcher.PropertiesToLoad.Add( "distinguishedName" ) | Out-Null
	$directorySearcher.PropertiesToLoad.Add( "objectClass" )       | Out-Null

	$results = $directorySearcher.FindAll()
	if( $results -ne $null )
	{
		msg "${indent}Search-PrimaryGroupId: found $($results.Count) results"
		foreach( $result in $results )
		{
			$myadspath   = $result.Path
			$objCount    = $result.Properties.objectclass.count
			$objectClass = $result.Properties.objectclass[ $objCount - 1 ]

			if( $objectClass -eq 'user' )
			{
				if( $dictionary.$myadspath -eq 1 )
				{
					msg "${indent}Search-PrimaryGroupID: continue duplicate user"
					return
				}
				$dictionary.$myadspath = 1
				$script:groupUsers++
				write-output $myadspath
				vmsg "${indent}Search-PrimaryGroupId: $myadspath"
			}
			else
			{
				write-error "Invalid objectclass for primarygroupid: $objectClass"
			}
		}
	}
	else
	{
		msg "${indent}Search-PrimaryGroupID: result from FindAll() was null"
	}

	msg "${indent}Search-PrimaryGroupId: exit"
}

function Search-Group
{
	Param(
		[string]$indent,
		[string]$ADSpath,
		[hashtable]$dictionary
	)

	### based originally on http://msdn.microsoft.com/en-us/library/bb885125.aspx
	### but has bug-fixes and enhancements

	msg "${indent}Search-Group: enter, $ADSpath"

	$groupDE  = New-Object System.DirectoryServices.DirectoryEntry( $ADSpath )
	$searcher = New-Object System.DirectoryServices.DirectorySearcher( $groupDE )
	$searcher.Filter = "(objectClass=*)"

	[bool]$lastLoop = $false
	[bool]$quitLoop = $false

	[int]$step = 999
	[int]$low  = 0
	[int]$high = $step

	do {
		if( $lastLoop -eq $false )
		{
			[string]$member = 'member;range=' + $low.ToString() + '-' + $high.ToString()
		}
		else
		{
			[string]$member = 'member;range=' + $low.ToString() + '-' + '*'
		}
		msg "${indent}Search-Group: member = $member"

		$searcher.PropertiesToLoad.Clear()        | Out-Null
		$searcher.PropertiesToLoad.Add( $member ) | Out-Null

		$result = $searcher.FindOne()
		if( $result -eq $null )
		{
			### not sure what to do here
			msg "${indent}Search-Group: searcher failure"
			break
		}

		if( $result.Properties.Contains( $member ) -eq $true )
		{
			$entries = $result.Properties.$member
			msg "${indent}Search-Group: entries.Count = $($entries.Count)"
			foreach( $entry in $entries )
			{
				if( $ExpandEmbeddedGroups )
				{
					$memberObj   = [ADSI] "LDAP://$entry"
					$objectClass = $memberObj.objectClass.Item( $memberObj.objectClass.Count - 1 )
					$myadspath   = $memberObj.Path
					$memberObj   = $null
				}
				else
				{
					$myadspath   = $entry
					$objectClass = 'user'
				}
				write-output $myadspath ### output to pipeline

				switch( $objectClass )
				{
					'group'
						{
							if( $dictionary.$myadspath -eq 1 )
							{
								msg "${indent}Search-Group: continue duplicate group"
								continue
							}
							$dictionary.$myadspath = 1
							$script:groupGroups++
							vmsg "${indent}Search-Group: group $myadspath"
							Search-Group ( $indent + '  ' ) $myadspath $dictionary
						}
					'contact'
						{
							if( $dictionary.$myadspath -eq 1 )
							{
								msg "${indent}Search-Group: continue duplicate contact"
								continue
							}
							$dictionary.$myadspath = 1
							$script:groupContacts++
							vmsg "${indent}Search-Group: contact $myadspath"
						}
					'user'
						{
							if( $dictionary.$myadspath -eq 1 )
							{
								msg "${indent}Search-Group: continue duplicate user"
								continue
							}
							$dictionary.$myadspath = 1
							$script:groupUsers++
							vmsg "${indent}Search-Group: user $myadspath"
						}
					'foreignSecurityPrincipal'
						{
							### do nothing
						}
					default
						{
							write-error "Search-Group: unhandled objectClass as member of group: $objectClass"
						}
				}
			}

			### could just say: $quitLoop = $lastLoop
			### but it's not a worthwhile optimization
			### (due to a loss of clarity in WHY)

			if( $lastLoop -eq $true )
			{
				msg "${indent}Search-Group: set quitLoop = true"
				$quitLoop = $true
			}
		}
		else
		{
			if( $lastLoop -eq $true )
			{
				msg "${indent}Search-Group: set quitLoop = true"
				$quitLoop = $true
			}
			else
			{
				msg "${indent}Search-Group: set lastLoop = true"
				$lastLoop = $true
			}
		}

		if( $lastLoop -eq $false )
		{
			msg "${indent}Search-Group: old low = $low, old high = $high"
			$low  = $high + 1
			$high = $low  + $step
			msg "${indent}Search-Group: new low = $low, new high = $high"
		}

	} until( $quitLoop -eq $true )

	$object   = $null
	$searcher = $null
	$groupDE  = $null

	$primaryID = Get-PrimaryGroupId $indent $ADSpath
	if( $primaryID -gt 0 )
	{
		Search-PrimaryGroupId $indent $script:defaultNC $primaryId $dictionary
	}

	msg "${indent}Search-Group: exit, $ADSpath"
}

function Search-ADForGroup
{
	Param(
		[string]$indent,
		[string]$group
	)

	msg "${indent}Search-ADForGroup: enter, group = $group"

	### build the LDAP search to find the group distinguishedName from the provided short name

	$rootDSE    = [ADSI]"LDAP://RootDSE"
	$defaultNC  = $rootDSE.defaultNamingContext
	$ldapFilter = "(&(objectCategory=group)(name=$group))"
	$rootDSE    = $null

	$directorySearcher = New-Object System.DirectoryServices.DirectorySearcher
	$directorySearcher.PageSize    = 1000
	$directorySearcher.SearchRoot  = ( "LDAP://" + $defaultNC )
	$directorySearcher.SearchScope = "subtree"
	$directorySearcher.Filter      = $ldapFilter

	### Define the property we want (if we don't specify at least one property,
	### then "all default properties" get loaded - that's slower).

	$directorySearcher.PropertiesToLoad.Add( "distinguishedName"  ) | Out-Null

	$groups = $directorySearcher.FindAll()
	if( $groups -eq $null )
	{
		write-error "Search-ADForGroup: No such group found: $group"
	}
	elseif( $groups.Count -eq 1 )
	{
		$script:defaultNC = $defaultNC
		msg "${indent}Search-ADForGroup: exit, $($groups.Item( 0 ).Path)"

		return $groups.Item( 0 ).Path ### same as ADSpath in VBScript
	}
	else
	{
		write-error "Search-ADForGroup: Multiple groups were found that match: $group"
	}

	msg "${indent}Search-ADForGroup: exit, null"
	return $null
}

	###
	### Main
	###

	if( $VeryVerbose )
	{
		$Verbose = $true
	}

	$result = Search-ADForGroup '' $group
	if( $result -ne $null )
	{
		$dictionary = @{}

		Search-Group '' $result $dictionary

		if( $Statistics )
		{
			write-host " "
			write-host "Users: $($script:groupUsers)"
			write-host "Groups: $($script:groupGroups)"
			write-host "Contacts: $($script:groupContacts)"
		}

		$dictionary = $null
	}

 

Creating Lots of Exchange Mailboxes for Testing Purposes

I'm in the process of developing a large new script and to test it properly, I needed to create several thousand new users with mailboxes. While I've previously written scripts like this for Exchange 2003, I didn't have one handy for Exchange 2007 and later.

So I whipped one up and decided to share! As you can probably tell, this script will create, by default, 6,000 users and mailboxes. You do have to tell it the password to assign, and you should change the $upnDomain to be a proper choice for your environment.

Enjoy!


Param(
	[int]$minValue =    1,
	[int]$maxValue = 6000,
	[string]$upnDomain = 'smithcons.local'
)

$password = ( get-credential UserName-Not-Important ).password

for( $i = $minValue; $i -le $maxValue; $i++ )
{
	$user = "User" + $i.ToString()
	New-Mailbox $user `
		-alias $user `
		-userprincipalname ( $user + '@' + $upnDomain ) `
		-samaccountname $user `
		-firstname $user `
		-lastname $user `
		-password $password
}

'Done'

 

How to Make Your PowerShell Session into an Exchange Management Shell

In my last blog post, Determining the Exchange Version Without Using Get-ExchangeServer,I showed how to read the Exchange version from the registry. Shortly after posting that, the questions began to roll in about "how to make my PowerShell session behave like the Exchange Management Shell".

Well, it's pretty easy.

In the New-ExchangeConnection function, I use "dot-sourcing" to minimize the work. When you dot-source something, it means you are basically including the contents of the file into YOUR file, at that location. So, I use the same setup that EMS uses; just changed to work on the proper version of Exchange, plus the little extra magic that usually happens behind the scenes, but doesn't because it's happening in my script instead of in the "real" EMS.

So here it is!


###
### New-ExchangeConnection
###
### Create a connection to an Exchange server, in a version
### appropriate way.
###

function New-ExchangeConnection
{
	### Load the versioning function

	. .\Get-ExchangeVersion.ps1

	$exchangeVersion = Get-ExchangeVersion
	if( $exchangeVersion )
	{
		switch ( $exchangeVersion.Version )
		{
			'2007'
				{
					### This first segment is handled by a PSConsole file in EMS itself
					Get-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin -EA 0
					if ($?)
					{
						## snap-in already loaded, do nothing
					}
					else
					{
						Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin
					}

					### This line makes the rest of the magic happen
					. 'C:\Program Files\Microsoft\Exchange Server\bin\Exchange.ps1'


					return 1
				}
			'2010'
				{
					### with the advent of remote PowerShell in E14, almost all
					### of the magic gets hidden
					$credential = $null
					$global:remoteSession = $null
					. 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'
					Connect-ExchangeServer -auto

					return 1
				}
			default
				{
					write-error "Unsupported version $($exchangeVersion.Version)"
					return 0
				}
		}
	}

	write-error "This is not an Exchange server"
	return 0
}

 

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
}

 

Finding Duplicate IP Addresses and Duplicate Names in a DNS Zone

One of the traditional issues associated with cleaning up an Active Directory Directory Services (AD DS) domain in DNS is to ensure that duplicate names in DNS are removed (this is typically an issue caused by not having DNS Scavenging enabled, or by having hosts forcefully removed from the domain and not properly cleaning up DNS). As a corollary, this can also lead to duplication of manually assigned IP addresses, regardless of whether those IP addresses are IPv4 or IPv6.

Duplications can cause issues for many different servers and services, including AD DS, Exchange, SharePoint, etc.

I've written a PowerShell script that can help you determine the duplicates in order to clean those up. See the script below!

## ## build-dns-objects.ps1 ## ## ## Michael B. Smith ## michael (at) TheEssentialExchange.com ## April, 2012 ## ## ## Primary functionality: ## ## Based on either an input file or the output of a default command: ## ## dnscmd ( $env:LogonServer ).SubString( 2 ) /enumrecords $env:UserDnsDomain "@" ## ## Create an array containing all of the DNS objects describing the input. ## ## ---- ## ## Secondary functionality: ## ## Find all the duplicate IP addresses and the duplicate names ## contained within either the file or the command output. ## ## By specifying the -skipRoot option, all records for the root of ## the domain are ignored. ## ## ## General record format returned by DNScmd.exe: ## ## name ## [aging:xxxxxxxx] ## TTL ## resource-record-type ## value ## [optional additional values] ## ## Fields may be separated by one-or-more spaces or one-or-more tabs ## [aging:xxxxxxxx] fields are optional ## Param( [string]$filename, [switch]$skipRoot ) function new-dns-object { return ( "" | Select Name, Aging, TTL, RRtype, Value ) } function tmpFileName { [string] $strFile = ( Join-Path $Env:Temp ( Get-Random ) ) + ".txt" if( ( Test-Path -Path $strFile -PathType Leaf ) ) { rm $strNetworkFile -EA 0 if( $? ) { ## write-output "...file was deleted" } else { ## write-output "...couldn't delete file, error: $($error[0].ToString())" } } return $strFile } if( $filename -and ( $filename.Length -gt 0 ) ) { $tmp = $filename } else { $tmp = tmpFileName dnscmd ( $env:LogonServer ).SubString( 2 ) /enumrecords $env:UserDnsDomain "@" >$tmp } $objects = @() $records = gc $tmp $script:zone = '' ## Primary functionality: foreach( $record in $records ) { ## write-output "Processing: $record" if( !$record ) { continue } if( $record -eq "Returned records:" ) { continue } if( $record -eq "Command completed successfully." ) { continue } $firstChar = $record.SubString( 0, 1 ) $record = $record.Trim() if( $record.Length -eq 0 ) { continue } $object = new-dns-object $index = 0 $record = $record.Replace( "`t", " " ) $array = $record.Split( ' ' ) if( ( $firstchar -eq " " ) -or ( $firstchar -eq "`t" ) ) { $object.Name = $script:Zone } else { $object.Name = $array[ 0 ] $script:Zone = $array[ 0 ] $index++ } if( ( $array[ $index ].Length –ge 3 ) –and ( $array[ $index ].SubString( 0, 3 ) –eq “[Ag” ) ) ## [Aging:3604987] { $object.Aging = $array[ $index ] $index++ } $object.TTL = $array[ $index ] $object.RRType = $array[ $index + 1 ] $object.Value = $array[ $index + 2 ] $objects += $object } ## Secondary functionality: ## There are more efficient ways to do this, but this is easy. ## search for duplicate names $hash = @{} foreach( $o in $objects ) { if( $o.RRtype -eq "A" ) { $name = $o.Name if( $skipRoot -and ( $name -eq "@" ) ) { continue } if( $hash.$name ) { "Duplicate name: $name, IP: $($o.Value), original IP: $($hash.$name)" } else { $hash.$name = $o.Value } } } $hash = $null ## search for duplicate IP addresses $hash = @{} foreach( $o in $objects ) { if( $o.RRtype -eq "A" ) { if( $skipRoot -and ( $o.Name -eq "@" ) ) { continue } $ip = $o.Value if( $hash.$ip ) { "Duplicate IP: $ip, name: $($o.Name), original name: $($hash.$ip)" } else { $hash.$ip = $o.Name } } } $hash = $null " " "Done"