Accessing ServerManager cmdlets remotely

I’ve been working on a little project of late that requires a Powershell script to check what roles a server has installed. Under 2008, this is fairly trivial as there is a ServerManager module for Powershell which can simply output which roles are installed. This is fine if you’re wanting to run the check locally, but what if you want to run it remotely? And if your local machine is not running 2008?

I tried to be sneaky and copy across the ServerManager module files but this didn’t work. I posted on the Microsoft powershell forums for help before I found the answer myself – use the invoke-command cmdlet. Below is an example of the code I used:

$strComputer = "someserver" # The server to run the command against
$strCommand = { import-module servermanager ; get-windowsfeature | Where {$_.installed -eq $true} | select displayname,name,installed,featuretype} # import the module, run the command to get the features that are installed
$FeatureList = invoke-command -computername $strComputer -scriptblock $strCommand # invoke-command against our remote server and run command we constructed

$FeatureList can then be manipulated as you see fit. This sort of thing could probably be used for a range of tasks.

VM Server #2 Upgrade

VM Server 1 is getting a bit overloaded so I’ve decided to upgrade a 2nd PC to act as a 2nd virtualisation host.  Upgrade components will be:

  • Gigabyte GA-P55-UD3R
  • 4 x 2GB OCZ DDR3 sticks
  • Intel i3 530 CPU

This should make it roughly the same specs as VM server 1 (ie. quad cores, 8GB of RAM).

Update: Turns out at least one stick of the RAM is completely defective (can’t even install the OS when it’s in) and the system occassionally blue screens with the other 3.  So now it’s down to just 3 gigs.  Also, the RAID array’s performance is being compromised by one of the drives lacking native command queuing.

Upgrades and how they can change

The “old” PC I have was upgraded to Windows 7 but it just couldn’t cut it. The poor thing was a dual-core Athlon X2 with only 2gigs of RAM and a 3-drive RAID 5 array. I have since found out that the support for the chipset on the board from nVidia is basically non-existant and there is no support for running Windows 7 on that platform. Add to that the woeful performance and I decided to upgrade… Halfway through doing the hardware upgrade I decided to put Windows 2008 R2 on instead and setup the machine as a second virtualisation system, as the primary is now getting overloaded. I’ll be fleshing out the details on the home network page over time.

Exchange 2010

I had a play around with the Exchange 2010 beta. It looked pretty good although the “killer” feature I wanted to check out, archiving, wasn’t fully functional. I’ve migrated my email from MailEnable to Exchange 2010. So far, I’m liking:

  • The database availablity group (DAG) feature looks very cool. Haven’t had the chance to test it fully.
  • The Unified Messaging feature set and management UI is a lot more developed. In 2007, it felt kind of half done (especially in 2007 RTM)
  • “Self service” of mailing lists sounds pretty cool but could be a problem in practice. Similarly, the Exchange Control Panel (ECP) allows sys admins the ability to manage Exchange from any web-enabled machine but whether you would is another issue.
  • The Powershell capabilities have matured which is a good thing.

Not liking:

  • The archive feature in its current form is pretty much useless. Most 3rd party archive implementations have two servers and/or storage systems – one with fast, smaller drives for the recent live email where disk IO performance is important, and one with slower, larger drives for the archive data where disk performance is less important than capacity. 2010 forces you to store the archive mailbox in the same database as the user’s main mailbox meaning your small fast SAS drives are being used up by archives.
  • Microsoft being a tad dishonest about using SATA drives for Exchange storage and pushing direct attached storage (DAS) over external storage solutions such as SANs and iSCSI. Yes you can use SATA drives, but according to their own storage calculator you’ll need 2-3 times the drives compared to SAS. For example, you might have a storage design that requires 8 SAS drives for the Exchange databases. With SATA, you would need 16-20 drives. Getting a DAS server chassis that can take those 8 SAS drives isn’t too difficult. Finding one that does 20 drives is more difficult and may compromise the design of other aspects of your server (RAM, CPU, etc).

Currently the server is running under Hyper-V and performing reasonably well considering the specs of the VM.

Upgrading to Windows 7

My new PC has been running Vista up until now. With the release of Windows 7 and the following positive praise for it, I decided to take the plunge. The sealing commentary came from some friends who had nothing but priase for Windows 7, while in the past they had complained constantly about Vista.

So I did all the right things, I ran the upgrade advisor tool. All my hardware was compatible. Only one application was not compatible – iTunes. The upgrade process itself was smooth and fast. The actual use of Windows 7 is pretty nice so far. The UI is very responsive.

I’ve completed three different install methods with Windows 7, just to see how they all work – the traditional installing from a CD/DVD, installing off a USB hard disk and installing via network using Windows Deployment Services (WDS). I think the WDS method ended up being the fastest, followed by the USB hard disk.

Hyper-V migration

I’ve been using VMware’s Server product for a while now for virtualisation. I mainly use it for testing things, like a Linux install or a new server product from Microsoft. I’ve decided to try out Hyper-V, partly to see how it measures up and partly because I’ve been getting performance slowdowns on my VMWare VMs.

Powershell Task of the Day – Move Mailbox for all users in an Organisational Unit (part 2, Bulk move)

A follow on from the previous script was to move a larger number of users in a list of OUs. To make the task easier, I decided to automate it a bit:

$miglist = import-csv c:scriptsmigration.csv

foreach ($item in $miglist)
{
$strTargetmbx = "EXCH02" + $item.tiernumber + "-east" + $item.tiernumber + "-east"
$strReportFile = "c:scripts" + $item.name + ".xml"
Get-Mailbox -server "EXCH01" -OrganizationalUnit $item.ouname | `
Move-Mailbox -Confirm:$False -TargetDatabase $strTargetmbx -SourceMailboxCleanupOptions DeleteSourceMailbox -ReportFile $strReportFile
}

In the first line, I’m importing the contents of a CSV file that listed the OUs, a friendly name for the OU and the “tier” database those users were to go in. Iterating through the $miglist, I construct the target mailbox database name ($strTargetmbx) and report filename ($strReportFile). The Move-Mailbox command uses the -Confirm:$False switch to suppress confirmation. If this switch isn’t used, you will be prompted for confirmation at each step. The rest of the move command is pretty simple, specifying where to move to and a report filename.

Powershell Task of the Day – Move Mailbox for all users in an Organisational Unit

I needed to migrate users from one email server to a new one with more storage. These users mostly fell into neat OU grouping. To do an OU at a time, I used the following command:

Get-Mailbox -server "EXCH01" -OrganizationalUnit "domain.local/Company/State/Office/Department/Team" | `
Move-Mailbox -TargetDatabase "EXCH02StorageGroup1Database1" -SourceMailboxCleanupOptions DeleteSourceMailbox –ReportFile c:migration_report.xml

The first line gets all the mailboxes in the specified OU. Line 2 performs the mailbox move, specifying the target database and a custom report file name for the results.

Powershell Task of the Day – Get Mailbox Size For Users in an OU

During an email migration, I wanted to see how many users would be under the new limits that would be imposed on them. In most cases, the restrictions would match their location in Active Directory. So I was able to export the needed details and view them:

# Process email stats for users in the specified OU and save to CSV file

Add-PSSnapin Quest.ActiveRoles.ADManagement
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin
Add-PSSnapin Microsoft.Exchange.Management.Powershell.Support

if (!$args) # Empty arguments
{
write-host "You must specify correct arguments, specify the OU to check, then the file name. ie. email_stats.ps1 domain.com/OUName/OUName2 oulist.csv"
}

write-host "Processing based on arguments..."
write-host "OU: " $args[0]
write-host "CSV: " $args[1]

$OUName = $args[0]
$FileName = $args[1]
$i=0
$strTest = "Name,Alias,ServerName,OU,TotalSize(KB)`n"

$arrMailboxList = get-mailbox -OrganizationalUnit $OUName | select name, alias,servername,organizationalunit
$arrMailBoxListCount = $arrMailboxList.count
foreach ($item in $arrMailboxList)
{
$i = $i+1
write-progress -id 1 -activity "Getting Mailbox List" -status "Progress:" -percentcomplete ($i/$arrMailboxListCount*100)
$arrMailboxStats = Get-MailboxStatistics -identity $item.alias | select displayname,totalitemsize
foreach ($stat in $arrMailboxStats)
{
$strTest = $strTest + $item.name + "," + $item.alias + "," + $item.servername + "," + $item.organizationalunit + "," + $stat.totalitemsize.value.toKB() + "`n"
}
}

Out-File -filePath $FileName -inputObject $strTest -encoding ASCII

This is my first powershell script using arguments. In this script, I was wanting to submit 2 arguments – the Organisation Unit to check and the CSV file to save the final results to. The basic work flow is to get all the users in the specified OU and then loop through the results, performing a Get-MailboxStatistics cmdlet on each. A CSV-formatted string is stored in a variable and then finally outputted to a CSV file.

Powershell Task of the Day – Bulk add to a distribution list

A follow on from the previous script, I had to then add some users to a distribution list. The following command was used:

get-user -organizationalUnit "domai.local/Company/State/OfficeLocation/Department/Team" | `
select UserPrincipalName | `
foreach { Add-DistributionGroupMember -identity "SA IP Agents" -member $_.UserPrincipalName }

Like the previous script, line 1 is getting users from he specified OU. In this operation, we really only need the User Principle Name. Line 3 iterates through the results, using the Add-DistributionGroupMember cmdlet to add the user.