PowerShell E2010 is not installed on this machine

After applying an update roll-up to Exchange 2010 server I ran into a problem when running the powershell script UpdateCas.ps1. This is the script updates the OWA site in IIS to fix the error where OWA could not initialize (usually with the error Couldn’t find a base theme (folder name=base)). It appears this script must be run each time Exchange is updated.

Unfortunately, when I tried to run the script in EMS I received the following error:

[PS] C:\Users\Administrator.000>cd “C:\Program Files\Microsoft\Exchange Server\V14\Bin”
[PS] C:\Program Files\Microsoft\Exchange Server\V14\Bin>UpdateCas.ps1
Add-PSSnapin : The Windows PowerShell snap-in ‘Microsoft.Exchange.Management.PowerShell.E2010’ is not installed on this machine.
At C:\Program Files\Microsoft\Exchange Server\V14\bin\UpdateCas.ps1:36 char:13
+ add-PSSnapin <<<< -Name Microsoft.Exchange.Management.PowerShell.E2010
+ CategoryInfo : InvalidArgument: (Microsoft.Excha…owerShell.E2010:String) [Add-PSSnapin], PSArgumentException
+ FullyQualifiedErrorId : AddPSSnapInRead,Microsoft.PowerShell.Commands.AddPSSnapinCommand
[10:00:01] ***********************************************
[10:00:01] * UpdateCas.ps1: 10/26/2014 10:00:01 AM
[10:00:04] Updating OWA/ECP on server DELLR710
[10:00:04] Finding ClientAccess role install path on the filesystem
[10:00:05] Updating OWA to version 14.3.174.1
[10:00:05] Copying files from ‘C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\owa\Current’ to ‘C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\owa\14.3.174.1’
[10:00:11] Found 1 OWA virtual directories.
[10:00:11] Updating OWA virtual directories
[10:00:11] Processing virtual directory with metabase path ‘IIS://DELLR710.AP.local/W3SVC/1/ROOT/owa’.
[10:00:11] Creating metabase entry IIS://DELLR710.AP.local/W3SVC/1/ROOT/owa/14.3.174.1.
[10:00:11] Configuring metabase entry ‘IIS://DELLR710.AP.local/W3SVC/1/ROOT/owa/14.3.174.1’.
[10:00:11] Saving changes to ‘IIS://DELLR710.AP.local/W3SVC/1/ROOT/owa/14.3.174.1’
[10:00:11] Saving changes to ‘IIS://DELLR710.AP.local/W3SVC/1/ROOT/owa’
[10:00:11] Update OWA done.
[10:00:11] Updating ECP to version 14.3.174.1
[10:00:11] Copying files from ‘C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\ecp\Current’ to ‘C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\ecp\14.3.174.1’
[10:00:12] Update ECP done.
Remove-PSSnapin : No Windows PowerShell snap-ins matching the pattern ‘Microsoft.Exchange.Management.PowerShell.E2010’ were found. Check the pattern and then try the command again.
At C:\Program Files\Microsoft\Exchange Server\V14\bin\UpdateCas.ps1:154 char:16
+ remove-PSSnapin <<<< -Name Microsoft.Exchange.Management.PowerShell.E2010
+ CategoryInfo : InvalidArgument: (Microsoft.Excha…owerShell.E2010:String) [Remove-PSSnapin], PSArgumentException
+ FullyQualifiedErrorId : NoPSSnapInsFound,Microsoft.PowerShell.Commands.RemovePSSnapinCommand

The update removed the E2010 and Support keys from the registry that the EMS was trying to call. Apparently Microsoft doesn’t want you running EMS scripts at the server. Instead we should be running them from a remote workstation. To see which plugins were available I ran the following command:

[PS] C:\Program Files\Microsoft\Exchange Server\V14\Bin>Get-PSSnapin –Registered
Name : Microsoft.Exchange.Management.PowerShell.Setup
PSVersion : 1.0
Description : Setup Tasks for the Exchange Server

Name : Windows.ServerBackup
PSVersion : 2.0
Description : This Windows PowerShell snap-in for Windows Server Backup contains cmdlets used to configure, run, and manage backups.

According to the command only two plugins have been installed. Fortunately the fix is easy – two keys need to be added to the registry. The two plugins that need their information added to the registry are Admin Tasks for the Exchange Server and Support Tasks for the Exchange Server. You can export the keys from a working Exchange server or you can create .reg files using the Pastebins below and merge the files.

Create two registry files by copying and pasting the code from Pastebin and then merge them by right-clicking on each one and selecting Merge. There is no need to reboot or restart Exchange services.

Now, when the Powershell script is run it completes without error:

[PS] C:\Program Files\Microsoft\Exchange Server\V14\Bin>UpdateCas.ps1
[10:48:17] ***********************************************
[10:48:17] * UpdateCas.ps1: 10/26/2014 10:48:17 AM
[10:48:17] Updating OWA/ECP on server DELLR710
[10:48:17] Finding ClientAccess role install path on the filesystem
[10:48:17] Updating OWA to version 14.3.174.1
[10:48:17] Copying files from ‘C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\owa\Current’ to ‘C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\owa\14.3.174.1’
[10:48:18] Found 1 OWA virtual directories.
[10:48:18] Updating OWA virtual directories
[10:48:18] Processing virtual directory with metabase path ‘IIS://DELLR710.AP.local/W3SVC/1/ROOT/owa’.
[10:48:18] Metabase entry ‘IIS://DELLR710.AP.local/W3SVC/1/ROOT/owa/14.3.174.1’ exists. Removing it.
[10:48:18] Creating metabase entry IIS://DELLR710.AP.local/W3SVC/1/ROOT/owa/14.3.174.1.
[10:48:18] Configuring metabase entry ‘IIS://DELLR710.AP.local/W3SVC/1/ROOT/owa/14.3.174.1’.
[10:48:18] Saving changes to ‘IIS://DELLR710.AP.local/W3SVC/1/ROOT/owa/14.3.174.1’
[10:48:18] Saving changes to ‘IIS://DELLR710.AP.local/W3SVC/1/ROOT/owa’
[10:48:18] Update OWA done.
[10:48:18] Updating ECP to version 14.3.174.1
[10:48:18] Copying files from ‘C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\ecp\Current’ to ‘C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\ecp\14.3.174.1’
[10:48:19] Update ECP done.
[PS] C:\Program Files\Microsoft\Exchange Server\V14\Bin>

The following image shows the two new entries for the missing plugins in the registry:

Registry code for Support Tasks on Pastebin
Registry code for Support Tasks on Pastebin

Repairing Exchange Discovery Mailboxes

I went to perform a Discovery Search on our Exchange 2010 server for the first time since installing the server. Naturally, there was a problem. When trying to create a search using the Exchange Control Panel (ECP) the response was an error and the search could not be saved. My first thought was to make sure the arbitration accounts were setup and had the correct permissions. So, in the Exchange Management Shell I ran the command get-user -arbitration which showed the system mailboxes were in an inconsistent state:

This fix for this problem is to delete the system accounts and recreate them. The following steps are what I did to recreate the system accounts.

1. In Active Directory Users and Computers delete the following accounts:
   • FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042
   • SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}
   • SystemMailbox{1f05a927-f5af-4646-bf20-4a3a41282c07}
     NOTE: The last account may be different but, should start with “1f05a927”
2. Open a Command prompt change directory to the setup files for Exchange. On my server this was located in:
   C:\Program Files\Microsoft\Exchange Server\V14\Bin
3. Run the command: setup.com /preparead. This will recreate the system accounts.
4. In the Exchange Management Shell run the following commands:
   • Enable-Mailbox –Arbitration –Identity “FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042”
   • Enable-Mailbox –Arbitration –Identity “SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}”
   • Enable-Mailbox –Arbitration –Identity “SystemMailbox{1f05a927-f91e-4cc2-b79a-00f3c790c250}”
     Note: last account name will be different. Copy-and-paste name from AD Users and Computers.
5. Still in the EMS run the following commands to set the display name and quota on the Federated mailbox:
   • Set-Mailbox –Arbitration –Identity “SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}” –DisplayName “Microsoft Exchange”
   • Set-Mailbox –Arbitration –Identity “FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042” –ProhibitSendQuota 1MB

After rebuilding the accounts the commands get-user -arbitration and get-mailbox -arbitration should report no errors:

The complete error I was encountering was:

[PS] C:\Program Files\Microsoft\Exchange Server\V14\Scripts>get-user -arbitration
Name RecipientType
—- ————-
SystemMailbox{1f05a927-f5af-4646-bf20-4a3a4128… UserMailbox
WARNING: The object AP.local/Users/SystemMailbox{1f05a927-f5af-4646-bf20-4a3a41282c07} has been
corrupted, and it’s in an inconsistent state. The following validation errors happened:
WARNING: Database is mandatory on UserMailbox.
WARNING: Database is mandatory on UserMailbox.
SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d82… UserMailbox
WARNING: The object AP.local/Users/SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9} has been
corrupted, and it’s in an inconsistent state. The following validation errors happened:
WARNING: Database is mandatory on UserMailbox.
WARNING: Database is mandatory on UserMailbox.
FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa… UserMailbox
WARNING: The object AP.local/Users/FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042 has been
corrupted, and it’s in an inconsistent state. The following validation errors happened:
WARNING: Database is mandatory on UserMailbox.
WARNING: Database is mandatory on UserMailbox.

Additional Resources:

http://social.technet.microsoft.com/wiki/contents/articles/5317.recreate-and-enable-missing-arbitration-user-accounts-and-mailboxes-in-exchange-server-2010.aspx

How to edit client permissions in Exchange 2010

Exchange Management Powershell window

Aside from the GUI Exchange 2010 gives you two ways to assign client permissions — the permissions that dictate what end-users or clients can do — to Public Folders. One is a Powershell command that will apply permissions to a single folder. The other is a Powershell script that will apply permissions to a single folder and all subfolders.

Command to add client permission to single folder:

Add-PublicFolderClientPermission -User ‘mydomain\jchaven’ -AccessRights ‘Reviewer’ -Identity ‘\Management\Former Employee Mailboxes\John Doe\Calendar’ -Server ‘servername.mydomain.local’

Powershell script to add client permissions to folder and below:

AddUsersToPFRecursive.ps1 -TopPublicFolder “\Management\Former Employee Mailboxes\John Doe” -User “jchaven” -Permission Reviewer

Note: The Shell doesn’t load scripts automatically. You must precede all scripts with .\ (a period, followed by a backslash). For example, to run the AggregatePFData.ps1 script, type .\AggregatePFData.ps1.

The collection of Shell scripts described in this topic is installed, by default, at <Exchange Installation Path>\v14\Server\Scripts.

See TechNet for more information

NOTE: You may need to change path to location of scripts in Powershell. When I tried adding location of scripts to PATH variable in a command prompt it did not work. Click on image to see what I mean.