SharePoint

Renaming SharePoint 2013 Server

I spent sometime today renaming SharePoint 2013 Servers for a project I was pulled in on. It involved using PowerShell cmdlets and other administrative tasks.

The project required me to “Clone” SharePoint farm servers to make template environments for demonstration and development task.

I originally followed steps provided here: Renaming SharePoint then later streamlined the process so its something I found useful. Here are my notes saved in PowerShell format so it could be run step by step using PowerShell ISE:

 

Best,

Jermal

The Truth – Single Sign On with Outlook and Office 365

After many twists and turns on this bumpy road of setting up a Hybrid Deployment of Exchange Online with AD Sync and ADFS for SSO.  I am faced with yet another issue.

Let me tell you what does work with the single sign on:

  • Outlook via Web Access
  • Office 365 Portal
  • Office 365 SharePoint
  • Office 365 Yammer
  • Office 365 Web Apps
  • Office 365 Lync Online

For the most part any Office 365 web services offered using a web browser, as long as its Internet Explorer.

Missing from the above list of working items is Outlook! That’s right; Outlook doesn’t work.

In fact; users of Outlook will be prompted to enter their credentials on first use.  Let me break right here and describe first use.

First use is any time you open Outlook, you will be prompt for a password to log in.  Unless you save it.

In addition to having to save your password locally in the Windows Credential Manager, you will need to update this password which was saved each and every time you change your password.

This is not my understanding of what the term “Single Sign On” was to be. Good job to Microsoft’s Office 365 Marketing Team.  You had/have so many of us as believers.

At this time I am very disappointed about the Outlook prompts for password credentials. Perhaps they will fix in the future.

Research

I was able to find the following ADFS White Paper on Office 365 Single Sign-On with AD FS which should provide more details.

I also found info confirming that Outlook wasn’t designed to support Single Sign On.  It has even been quoted “The Office 365 experience for logging on to Microsoft Outlook connections is also not expected to be a single sign-on experience.”KB2535227 (A federated user is prompted unexpectedly to enter their credentials when they access an Office 365 resource)

I apologize for the somewhat rant; but felt I needed to share this before many of you waste a lot of time and investment on trying to get something like this working, to only find out one of the major reasons to use it doesn’t work.

Perhaps Microsoft should read the Internet more before misusing terms such as SSO.

“With SSO, a user logs in once and gains access to different applications, without the need to re-enter log-in credentials at each application.”

http://www.techopedia.com/definition/4106/single-sign-on-sso

Single sign-on (SSO) is a property of access control of multiple related, but independent software systems. With this property a user logs in once and gains access to all systems without being prompted to log in again at each of them.”

http://en.wikipedia.org/wiki/Single_sign_on

Single signon takes away the need for the user to enter further authentications when switching from one application to another.”

http://www.webopedia.com/TERM/S/single_signon.html

Single sign-on (SSO) is mechanism whereby a single action of user authentication and authorization can permit a user to access all computers and systems where he has access permission, without the need to enter multiple passwords. Single sign-on reduces human error, a major component of systems failure and is therefore highly desirable but difficult to implement.

http://www.opengroup.org/security/sso/

– Jermal

SharePoint 2013: Upgrade to Claims Based Authentication

Claims-based authentication is an essential component to enable the advanced functionality of SharePoint 2013.

To move classic-mode web applications from SharePoint 2010 Products to SharePoint 2013, you can convert them to claims-based web applications within SharePoint 2010 Products, and then migrate them to SharePoint 2013.

The procedures in this post will address the issue I had faced after upgrading to SharePoint 2013 from 2010.

Due to classic mode authentication being officially depreciated by Microsoft, the database needed to be updated to claims based authentication.

During my testing; I noticed many (if not all) users accounts had issued logging into sites which worked prior to the upgrade.  I was removing and re adding them to work around this issue ; which was very tedious.

Using the Convert-SPWebApplication PowerShell command simplified this task.

Here are the steps I took

Launched SharePoint 2013 Management Shell as Administrator

Enter the following commands

Convert-SPWebApplication -Identity <URL> -To Claims -RetainPermissions

Please note the <URL> is the http://address to your SharePoint 2013 site application. Example: http://corp.jermsmit.com

For more info check out: http://technet.microsoft.com/en-us/library/gg251985.aspx

SharePoint 2013 Upgrade Testing – My InfoPath Issue

I have been testing various features and functionally of a  recent SharePoint 2010 to SharePoint 2013 upgrade I preformed. When I encountered an issue involving a list item used heavily buy one of my departments.

The issue presented itself when the users attempted to create new work items and this is when SharePoint 2013 displayed an informative error messages telling me something went wrong.

I was able to obtain the correlation ID,

and after some filtering and digging in the ULS  (Unified Logging System) I was able to see that this list was created using InfoPath.

After seeking additional information from a few developers it was suggested that this form may need to be recreated. I was later to find out that other customer shave been facing issues with InfoPath and SharePoint 2013 forms.

The Office Team @ Microsoft has released a statement via their Blog that they are “evolving  forms technology” in an effort to streamline and deliver a more integrated  user experience.

In their own words:  “we’re retiring InfoPath and investing in new forms technology across SharePoint, Access, and Word. This means that InfoPath 2013 is the last release of the desktop client, and InfoPath Forms Services in SharePoint Server 2013 is the last release of InfoPath Forms Services.” 

I am taking that means the older forms used from back in Office SharePoint Server 2007 have been deprecated, eventually the rest.

That said here is a link to their blog post:
Update on InfoPath and SharePoint Forms

 

SharePoint List View Lookup Threshold

Testing a pilot of a recent SharePoint 2010 to SharePoint 2013 upgrade I encountered a message reading: “This view cannot be displayed because the number of lookup and workflow status columns it contains exceeds the threshold (8) enforced by the administrator”

This seems to be resource throttling introduced in the web application to limit the number of items in a list view, which roughly means “woah, whats with the large database query dude”

I was able to locate where this throttling setting is located.

Open Central Administration > Application Management > Manage Web Applications (choose the application)> General Settings (a drop-down list should show, now select) > Resource Throttling

Scroll down and locate ‘List View Lookup Threshold‘ The default value is 8

Honestly, I have no idea how large this should be. I didn’t design the list. However Microsoft has some details of creating lists here. The only major concern here is obvious “Resources”.

So what I did was double the value that was the default

Please note that this solution by far is not 100% correct as I just tossed resources at an issue to resolve it. However without prior knowledge of list design this solution works.

Error seen on end user side: