O365 Disable SignInAccelerationDomain

February 10, 2016

After enabling the SignInAccelerationDomain acceleration setting for O365 via the post below, it took a while to figure out how to disable the darn thing.

https://technet.microsoft.com/en-us/library/fp161390.aspx

To disable or clear the setting the following command was the only one that worked for me:

set-spotenant -SignInAccelerationDomain ” ”

NOTE: there is a <space> between the two double-quotes!

 

 


Set Proxy for O365 PowerShell

July 31, 2014

Useful command to configure proxy server for PowerShell and O365 if you use a proxy at your place of work.

http://technet.microsoft.com/en-us/library/bb430772(v=exchg.141).aspx


Useful Excel Formulas

March 25, 2014

Found this today and it saved me some time counting occurrences characters within text:

http://support.microsoft.com/kb/187667

 


SharePoint Online PowerShell through Proxy Server

March 13, 2014

When trying to administer SharePoint Online (O365) via PowerShell through a proxy server the Connect-SPOService cmdlet connections fail.  The exception message is “Could not connect to SharePoint Online”.

To solve this, I put in the following two lines into my scripts prior to running the Connect-SPOService cmdlet.

$cred = [System.Net.CredentialCache]::DefaultCredentials
[System.Net.WebRequest]::DefaultWebProxy.Credentials = $cred

Connect-SPOService -Url https://contoso-admin.sharepoint.com -credential admin@contoso.com

References:

http://office.microsoft.com/en-us/sharepoint-help/introduction-to-the-sharepoint-online-management-shell-HA102915057.aspx


SharePoint 2010 Claims Migration Challenges

August 2, 2013

This post will outline challenges that I’ve experience when migrating a SharePoint 2010 classic mode web application to claims authentication.

First of all, the process that needs to be followed for claims migration is documented on TechNet here:

http://technet.microsoft.com/en-us/library/gg251985(v=office.14).aspx

NOTE: Be sure to review the “Additional migration guidelines” section at the end of the above article”.

Challenge #1 – InfoPath Browser Based Forms

In our deployment we have hundreds of InfoPath forms.  These forms make use of two items that break when moving to Claims; username() function and web service calls.

InfoPath username() function

This function is used within InfoPath to retrieve the current users account.  In a classic mode web application this function will return “domain\userid”.  Once the web application is migrated to claims, the updated format is the claims encoded value of “i:0#.w|domain\userid”.

This change is easily resolved by changing instances of username() to substring-after(xdUser:get-UserName(), “\”).

InfoPath Calling Web Services

We have many forms that make use of the User Profile web service to retrieve user information.  After the migration to claims, these web service calls were failing.  After some research, I found a couple of different methods to resolve this issue.

Option 1 (Watch out with this solution)

Check out the “Ensure IIS Authentication is Correctly Configured” section.  Once I made this change in IIS, the web service calls to the user profile web service were now working.

http://stevessharepointnuggets.blogspot.com/2012/03/infopath-2010-using-user-profile.html

After further research, it appears that this has some unfortunate side effects.  When Anonymous Authentication is removed from a claims IIS site, users receive a JavaScript error when using the delete document button on the ribbon.  Deleting a document from the ECB menu seems to work fine.  See the following KB article from Microsoft:

http://support.microsoft.com/kb/2850515

This option also breaks SharePoint Designer from being able to connect to SharePoint sites in the web application.

Option 2

Update data connections to web services in InfoPath forms to be UDC files AND configure the authentication for the web service connection to use static credentials OR retrieve an account from a Secure Store Target Application.

There are many examples of this online, but here is a detailed post on the entire process:

http://spvee.wordpress.com/2013/04/10/auto-populate-user-information-in-infopath-with-claims-based-authentication-part-3-of-3/

Summary

Ideally, I’d prefer option 1 above, but since this solution breaks deleting files from document libraries, this is not an optimal solution.

Option 2 works and is supported, but the fact that we will have to update hundreds of forms that call web services does not sit well with me.

Challenge #2 – Workflow Issues After Claims Migration

The next issue that we encountered after our test migration was complete was an error with workflows.  After the migration to claims, when clicking on an in progress workflow instance, the following exception would be thrown:

“Invalid WorkflowInstanceID parameter in URL”

The next logic step to troubleshoot was to try and take a look at the Workflow Association for the running workflow.  When clicking on the Workflows button on the ribbon for the library, the following exception was thrown:

“User cannot be found”

After running through many more upgrades and re-validating the upgrade steps, we found that the build of SharePoint 2010 we were on apparently causes these issues.  The farm version we ran into these issues was on build 14.0.6117.5002 which is the Feb 2012 Cumulative Update.  Knowing that we were preparing for the June 2013 Cumulative Update (14.0.7102.5004), the update was applied to our test farm.  After upgrading the claims migration process was run again and both of the above issues were resolved.  All in-flight and new workflow instances work as they should.

It appears at some point MS has fixed these issues, however, I’m not sure which CU it was fixed in.


Access Denied on Claims Web Application

July 18, 2013

After setting up a web application that uses windows claims, I set the portalsuperuser and portalsuperreader properties for the web application and granted the accounts the appropriate permissions via web application user policy.

Then I proceeded to load a site collection and was greeted with the Access Denied page. I have done this a couple of times now and always have an trouble finding the culprit.

Today I found the following blog:

http://blogs.msdn.com/b/andrasg/archive/2010/09/30/setting-the-super-user-account-on-sharepoint-2010-and-getting-access-denied-errors-afterwards.aspx

which has this reference in it:

“Moral of the story: if you are in claims mode, you will need to use the claims user name (i:0#.w|domain\user).”

I then changed my portalsuperuseraccount and portalsuperreaderaccount from “domain\account to the claims representation for this account of i:0#.w|domain\user, ran an IISRESET and problem solved!

Posting this to my blog so the next time I run into this issue I don’t have to hunt for the solution AGAIN.