Exchange Powershell Commands Missing from EMS

I just performed a fresh install of Exchange 2013 w/ SP1 on Windows 2012 Standard R2 which is also a domain controller in an organization that already has an Exchange 2010 server (on a separate server). When I launch the Exchange Management Shell and attempt to run "Get-ExchangeServer" I get the error "The term 'Get-ExchangeServer' is not recognized as the name of a cmdlet, function, script file, or operable program..." I see that \\HKLM\SOFTWARE\Microsoft\PowerShell\1\PowerShellSnapIns\Microsoft.Exchange.Management.PowerShell.SnapIn is loading the module name "D:\Program Files\Microsoft\Exchange\bin\Microsoft.Exchange.PowerShell.Configuration.dll" (which is the correct path to that file).

I've restarted the server twice and have the same issue. Also tried doing an unattended install of just the Managment Tools since using the setup GUI didn't give me the option of uninstalling and reinstalling the Management Tools since the checkbox is greyed out. I searched the ExchangeSetup log for errors and didn't find any.

How do I get the Exchange Management Shell to register the Exchange Powershell commands? Do I need to uninstall Exchange and Re-Install?

February 18th, 2015 3:28pm

Try running the following in your Exchange Management Shell:

add-pssnapin "exchange" -erroraction silentlycontinue

Then try running your command

Free Windows Admin Tool Kit Click here and download it now
February 18th, 2015 4:06pm

Thanks for the reply but unfortunately that didn't solve the problem. The command you specified seemed to work (no errors) but when I try to run any Exchange powershell command "get-exchangeserver", "get-mailbox", etc, I get the same error message: "The term 'xxx' is not recognized as the name of a cmdlet, function, script file, or operable program."

When I run get-pssnapin it shows:
Name: Microsoft.PowerShell.Core
PSVersion: 4.0

So it seems as though the Exchange PowerShell snapin isn't loading.

Interestingly, "add-pssnapin Microsoft.Exchange.Management.PowerShell.E2010" works but "...E2013" doesn't. I can at least do some basic tasks with this but I would like to get the server functioning properly before I start migrating the users since I'm sure in the future I will need some Exchange 2013 specific powershell commands.

February 19th, 2015 12:16am

From a remote machine, using a Powershell console started as an Exchange Organization administrator, can you try creating and importing a remote PSSession to the Exchange server ?The steps are detailed here. After importing the session, try doing a Get-ExchangeServer.
Free Windows Admin Tool Kit Click here and download it now
February 19th, 2015 3:17am

Hi Victor,

can you run any command at all?The account you tried to run this command,which Group is it member of?

February 19th, 2015 4:02am

Albert, it looks like Exchange powershell commands work when creating and importing a remote session to the Exchange server. I am able to run Exchange 2013 PS commands (e.g. Get-ExchangeServerAccessLicense, Get-MobileDevice, etc) using this method. Now the question is, why don't they run locally?
Free Windows Admin Tool Kit Click here and download it now
February 19th, 2015 10:04am

Just to eliminate something simple - doing a 'whoami' inside the local Powershell console on the server indicates the same  administrator account that could successfully logon remotely, correct ?
February 19th, 2015 10:07am

Off2work, yes, other basic (non-Exchange) Powershell commands work. User is a member of Organization Management and is an Enterprise Admin, Domain Admin, and Schema Admin so they should have full rights to everything. 
Free Windows Admin Tool Kit Click here and download it now
February 19th, 2015 5:58pm

Albert, yes, the same user is logged into both computers (local Exchange server and computer where I started the remote powershell session). Verified with whoami.
February 19th, 2015 7:53pm

please try to add user to Exchange org Admin,log out and back in again to server and try to run command again.Error Message seems like permission issue.
Free Windows Admin Tool Kit Click here and download it now
February 20th, 2015 2:27am

As stated above, the user is part of the Organization Management role already, which (unless I'm confused) is the highest-level role I can assign someone to for Exchange 2013.
February 21st, 2015 2:51am

Organization mnagement role doesnt grant you permission to manage Exchange server,for this you will need server management role: https://technet.microsoft.com/en-us/library/dd876866(v=exchg.150).aspx

https://technet.microsoft.com/en-us/library/dd638114(v=exchg.150).aspx

Plese give it a try and see if it helps

Free Windows Admin Tool Kit Click here and download it now
February 22nd, 2015 2:36pm

Added user to Server Management role and there is no change. Still cannot access the Exchange shell commands from the Exchange Management Console.

Sorry for the lag in response, I'm not getting the alerts that there is a reply.

February 22nd, 2015 11:54pm

did you log out and back in again on the server after you added Group?
Free Windows Admin Tool Kit Click here and download it now
February 23rd, 2015 5:51am

Yes. Still cannot access the Exchange shell commands.
February 26th, 2015 6:17pm

I don't think we set up split permissions in the domain/Exchange environment (unless I did it inadvertently). And there's nothing that says that installing Exchange on a domain controller makes it so that you can't use Exchange commands in the Exchange Management Console locally. That seems like something else entirely. 
March 5th, 2015 11:40am

Try below and confirm if that works.

1. Close Exchange Management Shell

2. Start -> Run -> %Appdata%

3. Open Roaming => Microsoft => Exchange => RemotePowershell

4. Delete or rename thethe folder which will have the nam equal to your Exchange server server1.domain.com

5. Open Exchange Management Shell and wait for the RBAC Stack authorization to complete where cmdlet will be added.

***VOTE IF HELPFUL / MARK ANSWER IF ANSWERS ***

Free Windows Admin Tool Kit Click here and download it now
March 5th, 2015 3:26pm

PK M, sorry, that didn't work either. I still can't run Exchange commands locally. Verified that re-launching the EMS created a new entry with my server name in \Microsoft\Exchange\RemotePowershell. 
March 5th, 2015 3:30pm

Open Powershell as Administrator.

1. Add-Pssnapin *Setup*

2. Install-CannedRbacRoleAssignments -InvocationMode Install -verbose

3. Install-CannedRbacRoleAssignmentSRAP -InvocationMode Install -verbose

4. Install-CannedRbacRoles -InvocationMode Install -verbose

Try the above commands and let me know if that helps

if that doesn't can you run the below command reply back with the output

Get-Command |?{$_.Name -like "Get-Exchange*"}

***VOTE IF HELPFUL / MARK ANSWER IF ANSWERS ***

Free Windows Admin Tool Kit Click here and download it now
March 5th, 2015 3:52pm

Ran the commands above. Steps 1 and 2 worked fine. Steps 3 and 4 were unrecognized commands.  Still can't run Exchange commandlets.

Here is the output of Get-Command |?{$_.Name -like "Get-Exchange*"}:

CommandType     Name                                               ModuleName                                          
-----------     ----                                               ----------                                          
Cmdlet          get-ExchangeServerGroupSid                         Microsoft.Exchange.Management.PowerShell.Setup      


   

March 5th, 2015 6:18pm

this works for me.
Free Windows Admin Tool Kit Click here and download it now
July 8th, 2015 4:11am

Hello,

I think the similar issue is described here: http://blogs.technet.com/b/nawar/archive/2014/02/06/microsoft-exchange-management-powershell-e2010-39-is-not-installed-on-this-machine.aspx

July 8th, 2015 4:19am

I checked out that article you linked but unfortunately it's not the same issue. When I run "get-pssnapin -registered" I get the following list: 

Name        : EnginePSSnapin
PSVersion   : 2.0
Description : Register cmdlets for Content Engine

Name        : HostControllerPSSnapIn
PSVersion   : 2.0
Description : Register cmdlets for Host Controller

Name        : InteractionEnginePSSnapIn
PSVersion   : 2.0
Description : Register cmdlets for InteractionEngine

Name        : JunoPSSnapin
PSVersion   : 2.0
Description : Register cmdlets for Juno

Name        : Microsoft.Exchange.Management.PowerShell.E2010
PSVersion   : 1.0
Description : Admin Tasks for the Exchange Server

Name        : Microsoft.Exchange.Management.PowerShell.Setup
PSVersion   : 1.0
Description : Setup Tasks for the Exchange Server

Name        : Microsoft.Exchange.Management.PowerShell.SnapIn
PSVersion   : 1.0
Description : Admin Tasks for the Exchange Server

Name        : Microsoft.Exchange.Management.Powershell.Support
PSVersion   : 1.0
Description : Support Tasks for the Exchange Server

Name        : Microsoft.Forefront.Filtering.Management.PowerShell
PSVersion   : 2.0
Description : Microsoft Forefront Filtering PowerShell Interface

Name        : SearchCorePSSnapIn
PSVersion   : 2.0
Description : Register cmdlets for SearchCore

Also when I look at the registry, all of the keys that should exist do exist

Free Windows Admin Tool Kit Click here and download it now
July 8th, 2015 12:13pm

Victor, what happens if you build a PSSession and import it from within the local machine itself, using the same procedure used earlier to connect remotely. Depending on the outcome, it might hint where to look next. Should this test be successful, it might be pointing to issues with the EMS shortcut invoking RemoteExchange.ps1.
July 9th, 2015 3:19am

If I build a PSSession and import it within the local machine it works. 

Don't know if this helps but this is what the EMS shortcut is running:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noexit -command ". 'D:\Program Files\Microsoft\Exchange\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto -ClientApplication:ManagementShell "

Free Windows Admin Tool Kit Click here and download it now
July 9th, 2015 11:40am

The shortcut is for a Powershell script that sets up various variables and loads Exchange related-types. The scripts is signed, so if text would be garbled it would fail to execute - so it's either one of the .ps1xml types or underlying .dlls being referenced that are broken, or some other subsystem the script depends on to run is broken (.NET underlying functions used only in the "client"-side connection, but not affecting the remote PS method tested earlier).

Checking all the referenced files against a baseline install might take time. It might be quicker to do a quick health check of the server first - there's a script release by Microsoft here that checks a bunch of things. Can you give it a go and let us know if it flags something critical ?

July 9th, 2015 12:27pm

This is the output of the health check. I imported the PSSession prior to running this and specified the FQDN of the server instead of localhost. (changed server name and domain name to generic in the output)

Calling Main Script Execution
Calling Normalize-ProcessorInfo
Calling Get-ServerRole
Calling Get-OperatingSystemVersion
Calling Get-LocalOperatingSystemVersion
Calling Get-NetFrameWorkVersion
Calling Write-SystemInformationToConsole
Exchange 2013 Health Checker version 1.12
System Information Report for servername.domain.local on 07/09/2015 09:34:07

Hardware/OS/Exchange Information:
Hardware Type: Physical
Manufacturer: Dell Inc.
Model: PowerEdge T430
Operating System: Microsoft Windows Server 2012 R2 Standard
Exchange: Version 15.0 (Build 847.32)
Server Role: MultiRole
Pagefile Settings:
Error: System is set to automatically manage the pagefile size.  This is not recommended.
.NET Framework:
Version: 4.5.2
Power Settings:
Power Plan: High performance
NIC settings per active adapter:
Interface Description: Broadcom NetXtreme Gigabit Ethernet #3
Warning: NIC driver is over 1 year old.  Verify you are at the latest version.
Driver Date: 2013-12-19
Driver Version: 16.4.0.2
Link Speed: 1000 Mbps
RSS: Enabled
Processor/Memory Information:
Processor Type: Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
Physical Memory: 65437 MB
Number of Processors: 2
Number of Physical Cores: 12
Megacycles Per Core: 2397
Number of Logical Processors: 24
Hyper-Threading Enabled: Yes --- Warning: Enabling Hyper-Threading is not recommended
Database and Mailbox Statistics:
Calling Get-DatabaseAndMailboxStatistics
Active Databases:
Mailbox Database 0311853838\servername
No Active Mailboxes found on server.

Passive Databases:
No Passive Mailboxes found on server.



Output file written to .\HealthCheck-servername.domain.local-07092015093404.log

Free Windows Admin Tool Kit Click here and download it now
July 9th, 2015 12:43pm

Any chance you can deploy CU9 on the Exchange Server 2013 box ? Since each Cumulative Update is essentially a full build, there's a high chance this might fix it.

I agree it would be interesting to see what's exactly causing it, but I'm running out of ideas.

July 15th, 2015 2:57am

Any chance you can deploy CU9 on the Exchange Server 2013 box ? Since each Cumulative Update is essentially a full build, there's a high chance this might fix it.

I agree it would be interesting to see what's exactly causing it, but I'm running out of ideas.

  • Marked as answer by victornegri 11 hours 56 minutes ago
Free Windows Admin Tool Kit Click here and download it now
July 15th, 2015 6:54am

I installed CU9 during a maintenance window but it didn't fix the problem. I still can't run Exchange commands in Powershell on the local server. "Get-Mailbox" (or any other Exchange command) is not recognized as the name of a cmdlet...
July 23rd, 2015 1:09pm

May be worth trying the powershell command again after cu9:

add-pssnapin "exchange" -erroraction silentlycontinue

Free Windows Admin Tool Kit Click here and download it now
July 23rd, 2015 3:42pm

Ran the add-pssnapin command and it did not make any difference. I also just tried add-pssnapin "exchange" and it gave me the error "The Windows PowerShell snap-in 'exchange' is not installed on this computer."

I then ran "Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn" and it worked and now I am able to run Exchange powershell commands. But when I close the EMC and reopen I have to re-run that command to get it to work. I know that this should be running on-load based on the reg key listed in my initial post. Any ideas on how to force it to run again on-load?

At least we're making progress!

July 23rd, 2015 3:56pm

Sounds like powershell profile issue, take a look at this article and add the "Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn" to your PS profile.

https://technet.microsoft.com/en-us/library/dd315342.aspx?f=255&MSPPError=-2147217396

Free Windows Admin Tool Kit Click here and download it now
July 24th, 2015 3:27pm

Thanks!
July 30th, 2015 3:37pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics