October 1, 2013 at 7:07 am #10447
I am pretty certain I already know the answer to this from reading the help files, but I want to make sure.
A team of SharePoint developers want access to specific cmdlets to update their custom application on a SharePoint 2010 Farm. I thought this would be fairly easy to do until I realized I couldn't use PowerShell 3.0 because the version of .NET Framework it uses breaks the SharePoint Farm.
I can't use a Session Configuration File because the Register-PSSessionConfiguration doesn't have a Path variable, and I don't see a way to limit a lot of the other parameters (like Visible Cmdlets) like you can with a Session Configuration File.
Am I pretty much out of luck trying to do this in PowerShell 2.0?
October 1, 2013 at 7:36 am #10452
In PowerShell 2.0, you had to write either a startup PowerShell script or a compiled DLL file to control session configuration options; the session configuration file functionality wasn't added until PowerShell 3.0.
Personally, I'd try to figure out why installing PowerShell 3.0 (and .NET Framework 4.0) breaks SharePoint. Different versions of the .NET Framework are supposed to run in parallel without interfering with each other, and the startup scripts needed to make this work in PowerShell 2.0 can be somewhat complicated.
If you do need to stick with PowerShell 2.0, this blog post (and the sample startup script that it links to) are a good starting point: http://ramblingcookiemonster.wordpress.com/2013/07/20/granular-access-via-powershell-remoting/.
Edit: If you happen to have a copy of Windows PowerShell In Action, Second Edition, this is documented in section 13.2.5 (Constraining a PowerShell session). Even though the book hasn't been updated for PowerShell 3.0 (or 4.0) at this point, it's still a pretty awesome reference. It explains why things work they way they do, not just how they work.
October 1, 2013 at 8:25 am #10454
My next plan is to look into the .NET issue because I am not about to give them admin rights to the server just so they can run some PowerShell scripts 🙂 . All I know is that after installing the 3.0 Framework the next deployment blew up and threw a bunch of errors about the .NET Framework being incorrect, and I couldn't troubleshoot at the time because they were in a time crunch.
October 1, 2013 at 1:22 pm #10460
There are known issues with PowerShell 3.0 on SharePoint 2010
These may help
October 2, 2013 at 5:04 am #10467
Thanks for those links, that is exactly the issue I was having! However, changing the shortcut path only partly resolved the issue. First though, some background.
Server: Server 2008 R2 SP1
User Account: Is a Farm Admin, Local Admin, has all appropriate rights to the SP_Config Database
When I run the Sharepoint 2010 Management Shell as Administrator, I can execute SP commands with no issue. When I run either Powershell or Powershell ISE as Administrator, I continue to get "The local farm is not accessible. Cmdlets with FeatureDependencyID are not supported."
The error when running a command is the following, with the only difference I can see from the articles you linked is that the version of .NET Framework is slightly different.
` Get-SPFeature : Microsoft SharePoint is not supported with version 4.0.30319.261 of the Microsoft .Net Runtime. At line:1 char:1 + Get-SPFeature + ~~~~~~~~~~~~~ + CategoryInfo : InvalidData: (Microsoft.Share...mdletGetFeature:SPCmdletGetFeature) [Get-SPFeature], Pla tformNotSupportedException + FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletGetFeature `
Edit: The reason I am trying to run the commands in Powershell ISE is that the SharePoint developers have created custom PowerShell scripts to run to deploy code for their custom application. In the past I have run these in PowerShell ISE, but I may have to just run them in PowerShell from now on. If I add -Version 2.0 to the PowerShell shortcut, everything loads fine and there are no errors. But if I try the same flag with PowerShell ISE shortcut, it freaks out. Doing some research it seems that it is not possible to run PowerShell ISE in 2.0 mode.
Thanks again for the links.
October 2, 2013 at 10:46 am #10475
You can dot source them as well so that the variables in those scripts stay resident. For example from a PowerShell prompt type in the name of your ps1 file like this
that's a single dot or period followed by a space and then a single dot representing the current directory and a backslash folder name. If your script is in the current directorry omit the folder name or path there and just put the file name after the backslash.
Dot sourcing your script allows you to continue to run the script functions over and over again from the command prompt and your variables and things will stay in memory. Sort of the way they do when you're run them in ISE and then use the shell in there to type the function names over and over.
You must be logged in to reply to this topic.