The tools that really caught my eye were their:

• Active Directory Change Reporter – this tool is great for environments with multiple administrators or environments that have delegated administration.  You get to see the before/after value of exactly what was changed and exactly who changed it.
• Inactive User Tracker – I would bet that nearly every Active Directory environment must have dozens, if not hundreds or thousands of accounts that haven’t been used for long periods of time.  This tool can help to identify these accounts and can even take action to eliminate those open risks.
• Password Expiration Notifer – I actually wrote an application one time that would pull the last change time stamp from Active Directory and send out an email notification to a user.  This solution does exactly the same thing only without code!  Very handy for users that may never get to a Windows based system where a password reminder is available (VPN, custom LDAP, portal, etc.).

Most of the older SQL Server versions required you to create a data transformation services (DTS) job to transfer the logins while the newer versions all you to execute some SQL scripts.  Either way Microsoft has produced two knowledge base articles on both procedures:

• http://support.microsoft.com/kb/246133
• http://support.microsoft.com/kb/918992

The testers also put the 32-bit and 64-bit versions of Windows to the test to see if there was any difference.  You can view the study in its entirety or you can just skip ahead to the results.

The bottom line of the tests show that you will get the highest number of active sessions with Microsoft Office 2003.  Suprisingly Microsoft Office 2007 isn’t all that far behind.  I ususally hear rumblings of how Microsoft Office 2007 is a memory hog but this test seems to debunk that myth.

I’ve come across a handful of things that were especially irritating when using the export-mailbox cmdlet so I thought it might be good to share them here.

The first thing I ran into was:  “The specified module could not be found., error code: -1073282946″ Gosh, that sure is a helpful message.  Maybe it would be easier to troubleshoot if you told me what specified module you were looking for!  Ok, not to worry, I have run into this on more than one occasion and the common thread seems to be the installation or uninstallation of Outlook or the Exchange management tools.  To fix this error, simply open a command prompt (can also be done from PowerShell or EMS) and type fixmapi.  That’s it, no special parameters or crazy syntax, just fixmapi.

I should also point out that the previous module could not be found error message also in some cases caused the Exchange Management Shell to crash completely.  In these cases it also left NO traces of its crash in any event log that I could find.

Now the export-mailbox cmdlet should work right?  Well… not exactly…

Instead of a freshly exported PST file, I am greeted by another helpful error message “Failed to copy messages to the destination mailbox store with error MAPI or an unspecified service provider” the error message goes on and has some meaningless numbers associated with it, but you get the point.  There are a couple of causes for this but to my knowledge there is little information out there on how to fix it.

1. You may not have permissions to the mailbox.  If this is the case you need to run the Add-MailboxPermission cmdlet.  If you have never worked with this cmdlet then you may have found your solution.
2. The account that you are running the Export-Mailbox cmdlet with MUST have an Exchange mailbox itself.  I know this might sound silly, but it is not uncommon to have separate admin accounts separate from your normal user accounts that do not have mailboxes.
3. I have read on a couple of forums that using some of the more advanced features of the Export-Mailbox cmdlet, such as the -EndDate parameter will also cause this error.  Also from what I have read, there is currently no fix for this.  Again this is what I have read… your mileage may vary.

Hopefully these quick tips will help someone save a few hours of wasted time on trying to do something as simple as export a mailbox.

Basically this has to do with the encryption that is used for terminal services licensing having changed its key size from 512 bytes to 2048 bytes.

Here is the link to the Microsoft Knowledge Base article: http://support.microsoft.com/kb/949914.  Unfortunately this is one of those hotfixes that you have to request from Microsoft.  The good news is that they aren’t making you jump through a lot of hoops to get it.  Mine came right away in an email!

1. Logon to the server core console
2. Enter the product key:  cscript C:\windows\system32\slmgr.vbs -ipk PRODUCT-KEY-HERE
3. Activate:  cscript C:\windows\system32\slmgr.vbs -ato

http://www.microsoft.com/downloads/details.aspx?familyid=3403d74e-8942-421b-8738-b3664559e46f&displaylang=en

Post – http://msexchangeteam.com/archive/2008/08/07/449501.aspx

Song – http://msexchangeteam.com/files/12/attachments/entry449511.aspx

To be fair, Microsoft still allows you to customize SOME settings when deploying using an MSI. There is a config.xml file that is contained in the same directory as the MSI that allows you to specify things like product key, organization name, and a few other basic items. If you don’t have a need to specify any configuration options and just want a plain vanilla install then you can still deploy Office 2007 using the tried and true MSI installation via Group Policy.

Keep in mind that if you do chose to use the MSI installation method, any patches you place in the Updates folder will be ignored! This is important for things like service packs or critical security updates.

To overcome this Microsoft recommends creating a script that will perform the install, then using Group Policy, apply this script as a computer startup script. I have taken that approach and modified it slightly to achieve a more controllable method whereby an end user can run the install or administrators can place this script into an already existing logon script. The advantage here is that the user will NOT have to wait for the installation to complete prior to logon.

So here goes:
@ECHO OFF

ECHO Detecting Outlook 2007...
IF EXIST "C:\Program Files\Microsoft Office\Office12\OUTLOOK.EXE" GOTO End ELSE GOTO InstallOutlook

:InstallOutlook
ECHO Outlook 2007 not found.
ECHO Please wait while the Outlook 2007 installation initializes...
START \\SERVER\Share\OL2007\setup.exe /adminfile \\SERVER\Share\OL2007\Updates\OL2007.MSP
ECHO Initialization complete.
GOTO End

:End
EXIT

Before you go trying to run this puppy, you will need to have already created a share, copied the installation to the share, and finally created a transform file that contains your desired configuration options. I won’t go into a bunch of detail on how to do all of this other than to say the command to enter the Office Configuration Wizard is setup.exe /admin

This particular bit of EMS code will allow for the creation of an E-mail address policy called North America that is based on the Co or country attribute in Active Directory. Of course we have chosen United States, Canada, and Mexico for this particular one but you could easily modify the syntax to create an unlimited number of combinations.

New-EmailAddressPolicy -Name 'North America' -EnabledEmailAddressTemplates 'SMTP:@contoso.com' -RecipientFilter {((Co -eq 'United States') -or (Co -eq 'Canada') -or (Co -eq 'Mexico'))}

At this point don’t worry about getting fancy with the SMTP addresses. Once this new policy is created you can use the E-mail Address Policy wizard to customize the addresses. The important thing is that the recipient filter must be created via the EMS.