Monday, March 08, 2010

This blog has moved


This blog is now located at http://blog.chrislehr.com/.
You will be automatically redirected in 30 seconds, or you may click here.

For feed subscribers, please update your feed subscriptions to
http://chrislehr.com/atom.xml.

Wednesday, March 03, 2010

PowerShell for Backup Planning

To size a backup system, you need to decide on a few key pieces of information: retention range, amount in GB of file data to be backed up & change rate on that data. For applications, you will need to know SQL database sizes and change rates. Same for Exchange.

luckily with powershell, it's quick and easy. I'm a lazy scripter so I'm sure this script could be much improved, but it worked for my purposes.

to send server name, volume name, volume size, and free space to a .csv file:

$computer="server1","server2","server3"
$credential=get-credential
ForEach ($item in $computer)
{
$disk = get-wmiobject -credential $credential -query "select * from win32_logicaldisk where DriveType='3'" -computername $item
foreach($drive in $disk)
{
$item + "," + $drive.Name + "," + [int]($drive.size/1gb) +"," +[int]($drive.freespace/1gb)|out-file test.csv -append
}
}

This script will ask you to login with administrator credentials, then output information for all local hard drives (no removable drives or CD-ROMs), and output it to a .csv file.

For clusters, it will only retrieve the primary member's information.

What about SQL? We can simply search for .mdf files and list their sizes. We could also use this same bit to search for LDF files or any other file type. This will output to a .csv file the Server name, the path of the .mdf file, and the file size.

$computer="Server1","Server2","Server3"
$credential=get-credential
foreach ($svr in $computer)
{$dbFiles = Get-WmiObject -credential $credential -Class CIM_DataFile -Filter "Extension = 'mdf'" -ComputerName $svr;
$dbFiles | ForEach-Object { ($_.csname) + "," + ($_.Name) + "," + ($_.filesize/1gb)}| out-file testsql.csv -append

}

Notice that both scripts loop through an array to find data. You could also use an active directory query to populate the array instead of entering the names manually.

by the way, I love how I can convert bytes to GB just by dividing by "1GB" - powershell has built in constants for translating file sizes. You can also divide by MB or KB.

BES Enterprise Express released yesterday!

Blackberry Enterprise Express has released.

There is a great comparison matrix for BES Enterprise Express and other BES products here

Unfortunately, for customers who adopted and recently bought or renewed their Blackberry Professional licensing, I have yet to find information about migrations, or the future of the "professional" product line. There is not a clear delineation that professional became Enterprise Express, but it does appear that way. I did find the old BES Pro PDF comparison on their UK site and was able to make this comparison below:

Labels: ,

Sunday, February 28, 2010

Errors moving mailboxes to an Exchange 2010 DAG

I ran into this today, doing my first production DAG with a copy on a kind of slow connection.

Error: Move for mailbox '/o=First Organization/ou=First Administrative Group/cn=Recipients/cn=user' is stalled because DataMoveReplicationConstraint is not satisfied for the database 'Database' (agent MailboxDatabaseReplication). Failure Reason: Database a409ab86-ce24-4fcf-bd2a-14fd633090aa does not satisfy constraint SecondCopy. Some database copies are behind.

Sure enough, a quick check of get-MailboxDatabaseCopyStatus showed that my CopyQueueLength was fairly high on the server across the WAN. As a result, my mailbox moves were failing with the above error. However, they don't fail right away, the StatusDetail shows StalledDueToHA. Some stayed there up to two hours waiting for the log shipping to catch up on the remote server before failing.

To show a more detailed output on move progress, I was using:
Get-MoveRequest Get-MoveRequestStatistics | ft displayname,*stat*,perc*,totalmailboxsize

So what Exchange 2010 is doing here is smart. Exchange Active Manager doesn't want that CopyQueueLength to be over 10 files, or the replay queue length over 50. More constraints here.

The workaround is to disable this limit, so your moves can occur and the seeding can occur over time. This is one of three Microsoft recommended fixes. One is fix your database health, one is upgrade your WAN. This third one is a workaround that should be reconfigured after the initial mailbox moves.

Set-MailboxDatabase -DataMoveReplicationConstraint None

The default here is SecondCopy. More information on the other settings at the link above. This change DOES require a restart of the Exchange Replication Manager service. Be forewarned, if you have a queue length already, the replication manager will hang on stopping and attempt to complete the copies before stopping, so it might take some time.

Of course, once your moves are done, and your database's CopyQueueLength is normalized, you should re-enable this constraint using:

Set-MailboxDatabase -DataMoveReplicationConstraint SecondCopy

Labels: ,

Thursday, February 25, 2010

Exchange and the loss of single instance storage

Great post up on the Exchange Team blog about SIS. I have talked about this to many customers, and it's nice to have a link to refer people to for an explanation.

http://msexchangeteam.com/archive/2010/02/22/454051.aspx


In short, single instance storage was invented when disks were expensive and massive amounts of storage cost companies a lot more money. It worked great on that scale. As Exchange gained in popularity, and those users gained data, the disk planning for Exchange became more important, as the random I/O that SIS wrote took more time to read in than a sequential I/O. By moving to a sequential read/write model, they were able to vastly improve IOPS. So now, disk space is cheap and plentiful. Server level 2TB disks are here/coming soon, and I have a few customers with plans to do DAG's on 2TB SATA's.

Labels: , ,

Tuesday, February 23, 2010

Normalizing Phone Numbers to E.164 format in Excel

Recently, I had the need to import some users for a large company. In order to populate as much of their Active Directory as possible, they wanted their phone numbers to be in a standardized format. Both Microsoft and Cisco have standardized on E.164 (additional information here) as a numbering standard, which basically starts with + [country code] + phone number.

This particular customer is US based only, so all the numbers in their spreadsheet had a US country code of 1. If I had a multinational organization, some additional coding would need to be done to account for other country codes.

My major need was to simply re-input all the different numbering standards the various internal organizations had inputted their phone numbers as. In other words, normalization. This helps to set up AD for later integration of OCS, or other VoIP systems, as well as Exchange 2007 or Exchange 2010 UM.

Either way, the Excel formula I was using here was the following:
=CONCATENATE("+1",SUBSTITUTE(SUBSTITUTE(SUBSTITUTE(SUBSTITUTE(SUBSTITUTE((SUBSTITUTE(A2,"(","")),")","")," ",""),"-",""),".",""),"x",";ext="))

In logical order..

  1. Replace ( with null
  2. Replace ) with null
  3. Replace space with null
  4. Replace hyphen with null
  5. Replace period with null
  6. Replace x with ";ext=" (which is the E164 standard for non-DID numbers)
  7. Concatenate the +1 country code

Here again without the horrible color:
=CONCATENATE("+1",SUBSTITUTE(SUBSTITUTE(SUBSTITUTE(SUBSTITUTE(SUBSTITUTE((SUBSTITUTE(A2,"(","")),")","")," ",""),"-",""),".",""),"x",";ext="))

The end result, computer readable phone numbers!

Labels: , , ,