27 October 2011

How do I – Resolve the Powershell New-SPConfigurationDatabase command error – The pipeline has been stopped, This SharePoint farm currently has pending upgrades

I was building a fresh SharePoint farm and issued the “New-SPConfigurationDatabase” Powershell commandlet when I was presented with the following error:

PS C:\Users\blog-spadm> New-SPConfigurationDatabase
cmdlet New-SPConfigurationDatabase at command pipeline position 1
Supply values for the following parameters:
DatabaseName: SharePoint_Config
DatabaseServer: SPSQL.Crayveon.com
FarmCredentials
Passphrase: *********
New-SPConfigurationDatabase : The pipeline has been stopped.
At line:1 char:28
+ New-SPConfigurationDatabase <<<<
    + CategoryInfo          : InvalidData: (Microsoft.Share…urationDatabase:
   SPCmdletNewSPConfigurationDatabase) [New-SPConfigurationDatabase], Pipelin
  eStoppedException
    + FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletNewSPCon
   figurationDatabase
New-SPConfigurationDatabase : This SharePoint farm currently has pending upgrad
es.  The cmdlet New-SPConfigurationDatabase cannot be executed until the upgrad
e is completed.
At line:1 char:28
+ New-SPConfigurationDatabase <<<<
    + CategoryInfo          : InvalidOperation: (:) [New-SPConfigurationDataba
   se], SPException
    + FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletNewSPCon
   figurationDatabase
PS C:\Users\blog-spadm> New-SPConfigurationDatabase
cmdlet New-SPConfigurationDatabase at command pipeline position 1
Supply values for the following parameters:
DatabaseName: SharePoint_Config
DatabaseServer: SPSQL.Crayveon.com
FarmCredentials
Passphrase: *****************
PS C:\Users\blog-spadm> 
The really silly outcome of this was not related to any upgrade or stopped pipelines or anything of that sort.  Yet another case of the error message NOT having anything to do with the actual problem.  As it turns out, the solution was in the farm Passphrase I was specifying.  The GUI version of PSCONFIG gives you notification when the specified farm passphrase does not conform to domain password policies, but the Powershell version does not.


I reran the exact same command but this time specifying a more complex passphrase that conforms to domain security policies, and the problem was solved!



Cheers
C

26 October 2011

03 October 2011

How do I – Solve the Access Denied error in SharePoint 2010 under Claims or Classic auth when accessing portal root while content access works fine

Sometimes in a SharePoint 2010 environment, you could encounter a problem where accessing a portal URL directly, e.g. http://portal.company.com. When attempting to access the URL, you could get presented with a simple “Access Denied” error such as this:

In addition, if you’re trying to access a NLB load balanced IP from your App server, you could be challenged for logon three time before getting Access Denied. The problem in this case is that the web application is thinking it has anonymous access enabled, but it actually does not. When a request for the root portal comes into the web app, the app does not challenge the requestor for credentials and when passed onto IIS without credentials and Anonymous Access not turned on, the result is an Access Denied error.
In order to resolve this, we will enable Anonymous Access on the web app and then turn it back off again.
Start by navigating to Central Administration.
Click “Application Management” in the left menu.
Under the Web Applications section, click “Manage web applications”.

A list of all your web apps is displayed.
Select the web app in question.
In the ribbon, click “Authentication Providers”

A popup window with your authentication providers opens. In our case, we see Claims.
Click the link under Zone, in our case “Default”.

Scroll down to the Anonymous Access section.
Check the “Enable anonymous access” check box.
Scroll down and click “OK”.

Now attempt to access your portal e.g. http://portal.company.com, and ensure that you’re able to resolve correctly. Once confirmed, simply follow the above steps again and uncheck the anonymous access check box this time. Once again check your access and all should be good.
Hope that saves someone some time.



Cheers
C

01 October 2011

Honored for the 7th time



I am honored today, to have received my 7th Microsoft MVP award for SharePoint. It’s been an incredible journey thus far and we’re only getting started. I look forward to what vNext will bring, but until then I’ll be spreading the word on my new SharePoint Disaster Avoidance Architecture for Large Scale Enterprises endeavor with my friend Jason Himmelstein.



Cheers
C

24 September 2011

Speaking at SharePoint Saturday New Hampshire



I’m speaking at the New Hampshire SharePoint Saturday event on 9/24 with my friend Jason Himmelstein. We will be presenting our famous Heavy Metal Power Pivot session. If you’re in the area, we’d love to see you so come on over and say hi!



Cheers
C

01 September 2011

How do I – Remove all traces of a Workflow from my SharePoint list?

Sometimes when we are working with SharePoint Designer (SPD) workflows on SharePoint lists, things can get a little ugly. SharePoint preserves every version of the workflow unless you manually go and remove it from the list settings. If you have a workflow that happens to keep in a running loop, it could appear as if the newly published workflow didn’t actually publish correctly. In such situations, it’s often better to “reboot” and publish fresh. What we would do is to remove every instance of our workflow from the list settings and then re-publish the workflow again from SPD. Here’s how:
  1. Start by navigating to the list on which the workflow was published.
  2. In the ribbon, switch to the “Library” tab.
  3. image
  4. Once on the “Library” tab, you can click the “Workflow Settings” button, but because the ribbon dynamically changes depending on browser size and screen resolution, that button may not always be displayed.  A sure way to get there is to click the “Library Settings” button which is always displayed.
  5. image
  6. From the Library Settings page, under “Permissions and Management”, click the “Workflow Settings” link.
  7. image
  8. You’ll now be presented with a long list of historic versions of the workflow.
  9. Click the “Remove a workflow” link below the historic list.
  10. image
  11. On the right, select the “Remove” radio button for every instance of the workflow.
  12. Once all the buttons are selected, click the “OK” button to completely remove our workflow from the list.
  13. image
  14. Now simply switch back to SPD and re-publish the workflow for a fresh start.

Cheers
C

SharePoint Remote Event Receivers are DEAD!!!

 Well, the time has finally come.  It was evident when Microsoft started pushing everyone to WebHooks, but this FAQ and related announcement...