Yeah, it has to do with some DLL's not being registered in the x64 environment until the console is launched. X86 works fine, as Roland has discovered, but gives other issues as you then have to run it in a X86 environment.
Just starts the console in the script and wait a few secs, or check for the DLL's to be registered, then carry on. I was thinking of registering the DLL's but it proved to be too many to make it worthwhile, so the ugly workaround was to launch the console. //A From: [email protected] [mailto:[email protected]] On Behalf Of Marable, Mike Sent: den 2 februari 2015 12:56 To: [email protected] Subject: RE: [mssms] CM Powershell provider not available in current PS-session I had a similar thing with some lab build scripts. Once the primary server was built I had to open the admin console first before any of the SCCM PoSh cmdlets would work. Almost like it had to be initialized first. Mike From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Andreas Hammarskjöld Sent: Monday, February 2, 2015 6:34 AM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] CM Powershell provider not available in current PS-session Hi Roland, You are probably running into the same issue that had me going nuts for a while. If you launch the admin console for that user before trying out the script it runs OK right? //A From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Roland Janus Sent: den 2 februari 2015 10:00 To: [email protected]<mailto:[email protected]> Subject: [mssms] CM Powershell provider not available in current PS-session I use PS to install all pre-reqs and CM itself, all working fine The problem is that the CM cmdlets don't work because the current PS-session doesn't know about the CM provider: Get-psdrive -psprovider cmsite returns nothing, hence I can't use Set-location either That's just for the current session, any new session works fine. That didn't show before since I had to invoke new x86 sessions to run those CM-cmdlets anyway, but with R2CU2 the cmdlets are native x64, so I could use the same original session. But that one doesn't know about the provider. I guess it's similar to env-variables in a CMD, where new values are unknown to the current cmd. Is there a way to let that session know about the change, like a "reload/refresh everything"? Or is there another way to use the cmdlets in that session anyway? -roland ********************************************************** Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues
