2
Vote

No snap-ins have been registered for Windows PowerShell version 2

description

Bug in the DPE prevents reporting against live FIM data using the FIM Configuration Migration Cmdlets. Workaround is to run the script as a task then consume the serialized results with the DPE to get around the need to load the snap-in (at least until I fix this bug!)

file attachments

comments

CraigMartin wrote Nov 16, 2011 at 4:37 PM

More detail: the workaround depends on PowerShell Remoting, so it has to be turned on and configured before this will work.

Sample workaround:

Problem DataSet Query Text:
Add-PsSnapin FimAutomation
Export-FimConfig -Custom "/Person"

Workaround DataSet Query Text:
Invoke-Command -Computer localhost -Script {
Add-PsSnapin FimAutomation
Export-FimConfig -Custom "/Person"
}

wrote Feb 25, 2012 at 5:29 PM

wrote Feb 13, 2013 at 8:51 PM

RonnyVanCraen wrote Feb 18, 2015 at 3:25 PM

Hi Martin,
I'm working with your PSDPE on Windows 2012 R2 and SQL server 2012. I was able to modified the Visual studio solution to let it work with our configuration and load the SPDPE and create some reports on Active Directory. Now we facing the same problem with the "No snap-ins have been registered for,..." when it try to add the Exchange 2007 snappin. We cannot use the invoke-command because Exchange 2007 doesn't support the remoting, I've did a lot of investigation about this subject. It would be nice if the SPDPE could use Powershell 64bit instead of the Powershell 32 bit. If I run the "Design The Query" with "Powershell DPE"
and the command [Environment]::Is64BitProcess > c:\temp\DPEprocess.txt I receive a false which means Powershell 32bit. Do you know how can I change in Visual Studio the Project References : "System.Management.Automation" to use Powershell 64bit. that would be great and solve all problems with snappins. Thanx in advance, Ronnny