Link to home
Start Free TrialLog in
Avatar of SAM2009
SAM2009Flag for Canada

asked on

Can't a Exchange 2010 snap-in in PowerShell script

Hi,

I my PowerShell script I try to add Exchange snap-in but I keep getting this error:

WARNING: Cannot load Windows PowerShell snap-in Microsoft.Exchange.Management.PowerShell.E2010 because of the following error: The type initializer for 'Microsoft.Exchange.Data.Directory.Globals' threw an exception.

The code I use is this one:

--------------------------------------------------------------------------------------
if (!(Get-PSSnapin | where {$_.Name -eq "Microsoft.Exchange.Management.PowerShell.E2010"}))
{

      try
      {
            Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010 -ErrorAction STOP
      }
      catch
      {
            Write-Warning $_.Exception.Message
            EXIT
      }
      . $env:ExchangeInstallPath\bin\RemoteExchange.ps1
      Connect-ExchangeServer -auto -AllowClobber
}
--------------------------------------------------------------------------------------

I heard that Framework .Net 4.5 might be the cause but even with 4.0 it works just for few moment.
Avatar of David Jones
David Jones

Install this and reboot, it requires .NET 4.5 but should fix your issue:
https://www.microsoft.com/en-us/download/details.aspx?id=40855
Avatar of SAM2009

ASKER

I already installed it and same problem. What is weird if I just force it to install without any verification it works. Like:

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010
You installed WMF 4.0 and not just .NET 4.5?
Avatar of SAM2009

ASKER

I even uninstall the 4.0 and reinstall it.  And 4.5 stays there.
You're not listening, good luck...
Click on the link I gave you, download it, install it, reboot. That link was not for .NET 4.5 it is a Powershell upgrade... Try not to assume things based on what is going through your mind please. The reboot is required and critical by the way......
Avatar of SAM2009

ASKER

Ha! Ha! David maybe I did not explain well but I did exactly what you suggested.

Before you suggested that I already had that hotfix so to make sure I uninstall the hotfix and reinstall it from the link you give me and reboot  but the result stay the same.
This needs to be installed on the exchange server.
In powershell what do you get when you execute: $PSVersionTable.PSVersion
Avatar of SAM2009

ASKER

Ok I did it in Windows 2008 server where I use ask task scheduler server. I will try in Exchange.
Execute Get-ExecutionPolicy and $PSVersionTable.PSVersion on both servers... Exchange and the other server..
Avatar of SAM2009

ASKER

From my Windows 2008 scheduler server:

In AD PowerShell:

Major  Minor  Build  Revision
-----  -----  -----  --------
4      0      -1     -1

In Exchange PowerShell:
Major  Minor  Build  Revision
-----  -----  -----  --------
2      0      -1     -1
Avatar of SAM2009

ASKER

In  Exchange 2010 server:

Both AD and Exchange PowerShell have:

Major  Minor  Build  Revision
-----  -----  -----  --------
2      0      -1     -1
That link upgrades you from Powershell 2.0 to 4.0, that exchange server is running 2.0 (reboot absolutely Required)

Also are you doing this in your plugin:
Add-PsSnapin Microsoft.Exchange.Management.PowerShell.E2010 from the "AD Server"?
Avatar of SAM2009

ASKER

As I said I did not run the update yet in Exchange server I did it in a Windows 2008 R2 where I install Exchange tool and use it as task scheduler server... to run schedule task like my script.


So what you said is if my task scheduler server run AD PowerShell version 4.0 and my Exchange 2010 server has AD PowerShell version 2.0 it might create this issue?
SOLUTION
Avatar of David Jones
David Jones

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of SAM2009

ASKER

Not sure I understand your question but I can tell you this:

If I use this code which check if the snap-in is installed first if not it will install...this give the error:
----------------------------------------------------------------------------------------------------------------------------------------------
if (!(Get-PSSnapin | where {$_.Name -eq "Microsoft.Exchange.Management.PowerShell.E2010"}))
{

      try
      {
            Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010 -ErrorAction STOP
      }
      catch
      {
            Write-Warning $_.Exception.Message
            EXIT
      }
      . $env:ExchangeInstallPath\bin\RemoteExchange.ps1
      Connect-ExchangeServer -auto -AllowClobber
}

----------------------------------------------------------------------------------------------------------------------------------------------

But if I just add the snap-in it works: Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of SAM2009

ASKER

Ya I read also the same link especially the first one. So If use the big code before importing AD module it works.
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of SAM2009

ASKER

Ok I see I will try tomorrow. Thanks for your suggestions.
BTW if at all possible use the hostname of the exchange server to connect the New-PSSession and not an IP because it will need more security like SSL if you choose an IP address to connect a PSSession. Surely you're using DNS in your AD installation though and can just use the name of the exchange server to establish the session extremely easily without the need for all of that as it will rely on the secure computer password / trust relationship in AD.
Please select a solution.
Avatar of SAM2009

ASKER

Thanks David for your help!
Yea NP, one thing to remember, PS 4.0 is the way to go for remote PS Sessions. If you have issues with them, first make sure you're running PS 4.0 on both machines, most important is the version of the remote system. If that isn't the issue, next look at the ExecutionPolicy of the remote system and in most cases, this will get you going.