Home Dashboard Directory Help
Search

Promblem with ProvisionGlobally() when using Management Framework on Windows 2003 by Mattias J Karlsson


Status: 

Active


6
0
Sign in
to vote
Type: Bug
ID: 531240
Opened: 2/5/2010 4:34:37 AM
Access Restriction: Public
0
Workaround(s)
view
6
User(s) can reproduce this bug

Description

This has earlier been reported as a Microsoft Case (SRZ091204000273) but without a resolution.

The problem we have is that on our Windows 2003 R2 SP2 SharePoint farm (3 WFE) we have created a PowerShell script to be able to recreate Web Applications in case of a disaster and recovery. The script worked fine until we installed Windows Management FrameWork Core. We then start to get the following error:
"ProvisionGlobally" with "0" argument(s): "Object reference not set to an instance of an object."

If you remove the Framework and reboot the script starts to work again. In our MS case we hade we used on request by MS to try the simpliest script to create a web application and provision it:

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")

$spFarm = [Microsoft.SharePoint.Administration.SPFarm]::Local

$spFarm.Name

$appBuilder = New-Object Microsoft.SharePoint.Administration.SPWebApplicationBuilder $spFarm

$spWebApp = $appBuilder.Create()

$spWebApp.ProvisionGlobally()

The above code does not work either when you have a farm. What happens is that on the machine where you run the script the IIS website and application pool is created but only on the local machine.

The same script on a singel server installation works fine and when using the Provision() or ProvisionGlobally()

In the MS case we tried the same code as a console application written i C# and that works fine. Using Central Administration is also working fine.

In addition we have also tried on several SharePoint farms and not only one.
Details
Sign in to post a comment.
Posted by Mark Ferraz on 4/14/2010 at 1:24 PM
I am also seeing the same problem. Script failure when using Provision(). We are going to have to hold off on the deployment of PowerShell 2.0 until this is resolved, which is a shame as we were hoping to use some of the new features...
Sign in to post a workaround.