Posts Tagged PowerShell

Powershell: The term ‘Get-ADUser’ is not recognized as the name of a cmdlet (SBS 2008)

We have immense power over our servers with Powershell.

There is so much we can do, or in the case of SBS 2008 (Powershell 2), a lot we wish we could do. I am trying to get a lot of info our of an AD in preparation of moving to a new domain controller. None of my AD scripts work. e.g.

  • Get-ADComputer
  • Get-ADUser

I am constantly getting “The term ‘blah’ is not recognized as the name of a cmdlet”.


After lot’s of reading and playing about, I got what I needed. I was able to install Active Directory Web Service on the machine and then use RSAT on a secondary computer.

So what do you do ?

Let’s start with Server 2008 R2 

You need to have installed

  • Active Directory Domain Services
  • Active Directory Module For Windows PowerShell
  • Active Directory Web Services

Run this at the Powershell commandline

>Import-Module ServerManager
>Add-WindowsFeature RSAT-AD-PowerShell
>import-module activedirectory

You should now be ready to go

Server 2008 or 2003

You need to install this hotfix. The links for this are hard to get working as Microsoft released this patch to only those that actually need it. It has not had very wide testing and has not been checked for what else it could break.

Install the Active Directory Management Gateway Service (Active Directory Web Service for Windows Server 2003 and Windows Server 2008)

Install RSAT on another PC (Windows 7, Windows 10 will be fine)

In powershell

>import-module activedirectory

You should now be ready to go

SBS 2008

Trying to install Active Directory Web Service for Windows Server hotfix as per the above outline, fails. You can try the 32 bit or 64 bit version and it will tell you it is not compatible.

You need to have the file NDP35SP1-KB969166-x86.exe, install it and reboot.

(KB 969166)

It will not install. What can you do? If you really need to get this hotfix installed (Warning, it is not fully tested) then here is a work around.

md c:\temp\AD_Management_Web
expand -F:* “Windows6.0-KB968934-x64.msu” c:\temp\AD_Management_Web
cd c:\windows\system32
start pkgmgr.exe /ip /m:c:\temp\AD_Management_Web\


Install RSAT on another PC (Windows 7, Windows 10 will be fine)

In powershell

>import-module activedirectory

You should now be ready to go

Useful links

Tags: , ,

So Exmerge is not going to natively work with Exchange 2007/2010. How do I export all the email? How do I move to a new server?

We have all grown to love and trust the Exmerge tool (It enables the import and export of emails between mailboxes and personal folder files (.pst). Exmerge is often used to perform brick level backups, enabling the backup/restore of individual mailboxes).

We used to manually export the clients Public folders from within Outlook and then magically rip out the remaining mailboxes behind the scenes (Overnight).
As long as the mailboxes are less than 2 Gb, as this is a limit with the PST files created with Exmerge, everything was automated and happened invisibly.

Now, we have less of a limit, as the newer PST files are limited to 20 Gb but … we don’t have Exmerge.

If you are using PS T’s to migrate mailboxes from one Exchange server to another, I have some options for you. You still have the move-mailbox procedure as an option but many of us end up in situations where the manual PST export is the Tool of choice.

With all of these options you still end up with a PST and there is a certain issue with replying to old email and calendar appointments that recur.
Look at

So, what do we do now?

Option 1: Sit at every PC and manually export all mailboxes to PST

Open Microsoft Outlook as each user account and resource mailbox on the network, manually export to PST.
On the new system, manually import each mailbox PST file back into a new MAPI profile for each user (Outlook is needed on a workstation).
Warn each user that replying to old internal emails might lead to failed email delivery. ( … and don’t bring over any nk2 files)

Job done but takes a long time. Also remember, Outlook 2003 versions and earlier are limited to 2 Gb PST files.

This is a boring tedious task.

Option 2: hack about with Exmerge.

The truth is that Exmerge does work with Exchange 2007. You don’t even need an Exchange 2000/2003 server within the company structure.
You can use the Exmerge included with the Exchange 2003 Tools but this needs to run from a client machine. You can’t run it on the server.

Exmerge 2003 requires the Exchange 2003 System Management Tools to be installed and for this to work you need IIS (Internet Information Services Snap-In) and some other tools.
You need to download and install the Windows Server Administration Tools Pack AdminPak.msi.
You then need an Exchange 2003 CD (the hard part). (You may also need a CD Key, the harder part). Select to install only the Microsoft Exchange System Management Tools component.

The final step is to check the Exchange service pack level and install this to your new management Pc.

The latest Exmerge is available for download from

Extract out the Exmerge.doc, Exmerge.ini and Exmerge.exe files and copy all files to the Exchange bin directory created by the Exchange System Management Tools installation.

The user account running Exmerge now needs access rights to the processed mailboxes. (Much the same as it did in Exchange 2000/2003)

We need to delegate the user with ‘Exchange View Only Administrator’ role and give the user Send As and Receive As permissions over the mailbox store. (Same requirements as in Exchange 2003 etc, different procedure).

Note: as with previous versions of Exchange, the Administrator and Administration groups inherit a deny security setting for the Send As / Receive As permissions. The user we create cannot be an administrator.

 At the Exchange Server, delegate ‘Exchange View Only Administrator’ control to the user you created.

Open the Exchange 2007 Management Console and select ‘Organization Configuration’

At the right-hand Action pane, click on ‘Add Exchange Administrator’

Add the account you want to use.

PowerShell –
Add-ExchangeAdministrator -Identity ‘domain.local/Users/ExMerge’ -Role ‘ViewOnlyAdmin’

You can now log your management PC on as the user, open the Management tool and it should look like the old ESM in Exchange 2003.
We now need to give the Exmerge user Send As and Receive As permissions on the Mailbox Store.

PowerShell –
Get-MailboxDatabase -identity “servername\First Storage Group\Mailbox Database” | Add-ADPermission -user “domain\ExMerge” -ExtendedRights Receive-As, Send-As

You can now run Exmerge from your management PC against Exchange 2007. Run Exmerge from within the bin folder, put in the domain information and user information as normal, select the two step process select all the mailboxes and export to your selected location.

It would be a good idea to look in the ESM at the mailbox sizes and make sure that they are all under 2 Gb.

Option 3: Third Party tools

There are lots out there. Ontrack PowerControls has worked for me in the past and can allow you to crack open an offline EDB exchange file. This is my favorite method and the most expensive. These tools have saved my bacon in many high stress recovery situations.

Option 4: Pure PowerShell

Please note: Export/Import to PST must be run from a 32 bit client machine with Exchange Management Tools installed (Version Exchange 2007 SP1 or later).  The 32bit requirement comes from a dependency with the Outlook client.

Install Outlook 2003 SP2 or Outlook 2007 on your management PC.

You can download Exchange 2007 Sp1 32-bit (E2K7SP1EN32.exe) from
You will need to install PowerShell (It is a part of Windows 7)
You will need MMC 3.0 

Once PowerShell and MMC 3.0 is all working on your management PC, run E2K7SP1EN32.exe and run the setup.exe. Do a custom installation. Select only the Exchange Management tools.

 After many system updates and a few reboots later you are ready to check all your permissions and do the PST export.

You need the following:

  • The user running the task must be an Exchange Organization Admin or an Exchange Server Admin on the server where the mailbox to export/import lives.
  • The user running the task must also have full mailbox access to the user mailbox you want to export/import.
  • To use the export-mailbox cmdlet, the source mailbox must reside on either Exchange 2007, Exchange 2003 SP2 (or later), or Exchange 2000 SP3 (or later).
  • To use the import-mailbox cmdlet, the target mailbox must reside on an Exchange 2007 mailbox server.
  • You cannot import or export data to or from a mailbox in a Recovery Storage Group
  • You cannot import or export data to or from a public folder.

To get started, you need to grant your user access. I create an Exmerge account in the Active Directory to do this with.
You can use the Exchange console to set the permissions . Use the Manage Full Access permission tool on the mailboxes node.

PowerShell –
Get-Mailbox | Add-MailboxPermission –user Username –AccessRight FullAccess –Inheritancetype all

Now you need to export the mailboxes to PST Files

PowerShell –
Export-Mailbox –Identity <mailboxUser> -PSTFolderPath <pathToSavePST>

PSTFolderPath must be a full path pointing either to a directory or to a (.pst) file. If a directory is specified a PST file named after the mailbox alias will be used as the target of the export. Note that if the PST file already exists the contents of the mailbox will be merged into it.

I have found in practice that the PST file that is produced is larger and contains more email than the mailbox. Maybe it pulls out the item retention items as well ?

This seems rather painfull in comparrison to Exmerge. That was a set and forget and run over night tool. This seems to be mailbox by mailbox?
Try this

Get-Mailbox -Database “mailbox database” | Export-Mailbox -PSTFolderPath D:\PSTs

Now we are at the new destination domain. The second half of the Exmerge 2 step process. You can import all the email pst files one at a time in Outlook logged in as each user or import with Powershell.

Import-Mailbox -Identity <mailboxUser> -PSTFolderPath <PSTFileLocation>

PSTFolderPath must be the full path to the directory where the .pst file lives or to the (.pst) file itself. In the case where PSTFolderPath points to a directory the cmdlet will try to match the mailbox alias with the name of an existing .pst file in the specified directory and import the content of that file.

When bulk importing mailboxes the PSTFolderPath must forcefully point to a directory and the task logic will try to match mailboxes alias with the .pst file names under that location. If no match is found for a particular mailbox, that mailbox will be skipped.

Powershell –
Get-Mailbox -Database “mailbox database” | Import-Mailbox -PSTFolderPath D:\PSTs

Let’s say you want to get fancy.  This is the power of PowerShell over Exmerge. Lets filter content in Export/Import to PST files.

Export/Import to PST support the following filters: Locale, StartDate, EndDate, ContentKeywords, SubjectKeywords, AttachmentFileNames, AllContentKeywords, SenderKeywords, and RecipientKeywords.
Example: Import only those messages that were created between 1/1/10 and 30/1/11 and contain the word “Exmerge” in the subject and any of the words {“ESM”,”2003″} in the body.

Import-mailbox -Identity user -PSTFolderPath D:\PSTs -StartDate 1/1/10 -EndDate 30/1/11 -SubjectKeywords:’Exmerge’ -ContentKeywords:’ESM’,’2003′

Much better than Exmerge. I think you can start to see many other uses for PowerShell.

The last option (option 5) is a Migration. That is a big topic and a whole other post.

 It belongs in this post but this one is long enough and I have a headache !

Tags: , ,