Upon searching the webs I came across a couple of TechNet forum posts that talked about rebooting the server to rectify the situation. However, later on in the forum post it was commented that it would work temporarily and the error would come back again.

Luckily I ran across a blog that talked about this issue and a fix without having to reboot the SharePoint server. The Point Beyond website talked about logging onto the server with the account the error displayed to create a User Profile on that server. This should rectify the situation. Low and behold that did work, temporarily. I will let you know if anything changes. Of course I do wish the blog mentioned why it worked, but that is another time. Good luck!

</don>

In an earlier blog post I talk about why I believe this is a critical role, but to paraphrase what said. Ultimately a SharePoint Site Owner will be a business user embedded in a department who understands that departments processes and content. This is an important concept to understand from the beginning of your SharePoint implementation and having them help with that implementation by bouncing ideas around will be very beneficial. They could potentially end up being the foundation of your internal Governance and SharePoint User Group.

When it comes to training these individuals it is important to keep in mind the training will be about a semi-IT related topic. Information will be centered around a web application with many more new terms and features than before to somebody who is a business person. In essence it will take time for them to assimilate and make sense of the information they are hearing. Here are some of my thoughts as to how to train your Site Owners.

• Give your Site Owners a playground to practice in before and after the training. This can be a different site collection within the SharePoint Farm or even a development version. Anything that will replicate the look and feel of your production environment.
• Start with the basics of SharePoint: Navigation, terminology, adding content, setting alerts, working with documents.
• Move into semi-advanced topics: creating sites, lists, libraries with configuring document management features. You may want to introduce what a web part is and some basic configurations.
• As they begin to understand what the product can do then get into advanced topics: Content Types, Site Columns, Metadata, Document ID’s (2010 version), etc.
• Ultimately you will need to ensure that what you are teaching the Site Owner is within the scope of your SharePoint implementation. For instance, if you are using Office Web Application make sure to talk about the user impact of clicking on the link versus opening in the client.

After each of the training session make sure to give the Site Owner a chance to practice and work on their site. Give them support as they learn by doing and give them ways to refresh what they have learned. Here are some options:

• Record the training sessions and make them available on a Site Owner training site.
• Utilize the Productivity Hub 2010 or Productivity Hub 2007 site collection and recreate a learning path with specific content they can use.
• Utilize Microsoft’s online help for both SharePoint 2007 & 2010.

The last thing I would like to mention is around the training itself. Some organization find they have internal staff that can do the training. Make sure they fully understand what features and functionality you are going to be using within SharePoint and the organization.

Another option is to find a Microsoft Certified Partner Learning Services (CPLS) for a specific course that will help give a hands on training for your Site Owners. You can find a local CPLS here on the Microsoft website. There are a handful of Microsoft courses that are out there. I am particularly partial to the Microsoft SharePoint 2010 Site Collection and Site Administration (50547) course since I co-authored the title.

I truly hope some of this information has been helpful and would love to hear your thoughts and comments on what you have seen around this topic. Thanks.

</don>

In our scenario we have a SharePoint 2010 Enterprise installation with multiple site collections and web applications all utilizing claims and SSL. A typical installation for most of our clients.

Everything was going great with hiding sections and removing and replacing with new fields however when I went to use the User Profile Web Service like I have done countless times before I receive the non-descript error of “An error occurred while trying to connect to a Web service. Log ID:5566” along with a Correlation ID and other gibberish.

Looking into the SharePoint Log files did not give me much to go on. On search the webs I was able to track down a couple options for solving this issue. I came across this forum post that detailed at the end how to troubleshoot when you cannot connect in a Claims scenario. This was helpful because in most of my work I have not had to use a data connection with with InfoPath or a Secure Store application. I would either use the Username() function or the User Profile Web Service would just work.

So I rolled up my sleeves and go into doing the following:

1. Create a new Secure Store Application and assigned the SPContent account. See Instructions Here.
2. Move the InfoPath User Profile Web Service connection to a data connection library within SharePoint. See Instructions Here.
3. Downloaded the data connection from the library (.ucdx file extension) and modified the authentication section based on the Claims scenario blog information. See Instruction Here.
4. Replaced the connection in the library with the modified connection.

After all of that something was working but not how I figured. When I would set up the Travel Requestor field with the recently configured web service it ended up bringing back the SPContent user name not the current user.

After a little more research on the webs I came across a very obscure Microsoft SharePoint Forum post where Peter Newhook not only talked about the adding the Secure Store application authentication section but also how to use InfoPath to query the web service with a concat (“domain\”,username()) function. Because we were in a Claims environment I had to accommodate the use of SharePoint claims and how it modifies the Username with i:0#.w|domain. This is what I ended up coming with that finally worked.

I hope this post has been helpful with similar scenarios you come across.

• Interactive Portal – Scott Yokiel
• General Mills Connect (Custom MySite & NewsGator integration) – Jenny Hon
• SharePoint Interactive Voice Response Integration – Doug Splinter

This month’s meeting will be at the Microsoft Technology Center in Edina or you can catch it on line. Check out the Minnesota SharePoint Users Group website for more information at www.sharepointmn.com. Look forward to seeing you there.

Based on numerous blog posts and my experience with IIS I started down the typical fixes:

• Manually start the individual web application
• Make sure the Identity on the web application was correct and the right credentials were in place
• Even running the SharePoint Configuration Wizard to fix any issues

After each one of these I would try hitting SharePoint Central Administration and would get a Server Not Available 503 error then go back into IIS and the web application would be stopped.

I then started looking into the ULS and Event Viewer to dig a little deeper.I started to see a pattern of something did not have permissions across these multiple web applications. Finally I searched the webs on a Application Event ID error of 5059 that basically said that “Windows Process Activation Service (WAS) encountered a failure when it started a worker process to serve the application pool.” Luckily this error pointed me to the follow SharePoint Forum post that got me on the right direction.

In essence there was a specific permission needed by SharePoint to allow the Identity for the web application to work. The local security policy of “log on as a batch job” user permission needs to be in place. My theory is when the domain went down a older version of the domain policy was pushed out and removed those permissions.

I ended up going into Group Policy Management console and had to find the policy where this was set. In this case the Domain Default Policy. The Log on as a batch job setting is found in Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment > Log on as a batch job. Afterwards I did a gpupdate /force and restarted the SharePoint server and everything was happy.

Hope this helps somebody else!

The other issue comes around how SharePoint likes to display dates when using Content Query Web Parts (CQWP). Even though you probably set up the Date/Time field to only display Date when it comes across in a CQWP you will still get the time component zeroed out as you can see in the example below.

The typical way to handle this would be to go in and modify the XSLT and not display this. There are plenty of resources that talk about that. However there are times when we may not have the time or experience to modify the XSLT. This is where calculated columns can come in very handy.

**Note: This ability to use a calculated column is available not only in SharePoint 2010 but also in SharePoint 2007.

To implement go into the list or library and create a new column. Name the column and make sure to select Calculated (calculation based on other columns).

In the Formula section add the following syntax:

=TEXT([Date Column Name Goes Here],”mm/dd/yyyy”)

Leave all other options default and click on OK.

Now when you go to the CQWP use the new text column instead of the older date column in the Fields to Display section and your information should display appropriately.

Your finished product should look like this:

Resources:

So I found this resource to be beneficial when I was working on this. Enjoy!

MSDN – Calculated Field Formulas

Over the last 4-5 months I have had to do many Forms Based Authentication (FBA) setups. This blog post and follow-up posts will talk about what should happen to make this work in a typical FBA environment. Now you are probably saying there are plenty of blogs that talk about this. I would agree and I will be referencing some of them. However not all of them talk about what are you going to do when things go wrong! That is what we will look at in the last installment.

1. Beginning FBA Configuration and Settings up Claims based Web Application
2. Working with Web Configuration Files
3. Using the CodePlex SharePoint 2010 FBA Pack
4. When FBA Goes Bad!

One FBA Scenario

In this scenario we are going to be setting up FBA within SharePoint for a typical extranet installation. This solution will not require any development of user management pages or branding, however these are options that need to be considered. So what are the different options when it comes to user management?

1. Make changes right in SQL – I don’t know about you but in most organizations this is not really a legitimate option. For testing purposes, adding users to SQL is a must. Check out this post from MSDN about this process.
2. Develop the controls and pages that will be used to support user management. This is not always a viable option if there is not a developer within your organization.
3. Download the SharePoint 2010 FBA Pack. We are going to talk through this in a later post.

Before Configuration Begins

It would be a good idea to talk a little bit about gathering some information prior to configuration of FBA. Besides the question of which user management solution to use, some discussion needs to be made to determine how many roles need to be considered. Roles within FBA equate to Active Directory (AD) groups. Because everything is in SQL we do not necessary have access to AD groups, this is the typically the purpose of implementing FBA. As you create users within SharePoint FBA you can assign a specific role to them. These roles can then be assigned to SharePoint groups or used within SharePoint permission.

Beginning FBA Configuration

With something like this we need to make some basic assumptions:

1. You are on Windows Server 2008 R2 for SharePoint and SQL
2. You are using SharePoint Server 2010 or SharePoint Foundation 2010
3. Your database is SQL Server 2008 or 2008 R2
4. And on the SharePoint box you have ASP.NET/IIS Administration up and running
5. SharePoint 2010 Web Applications are configured to run in Claims Authentication (rather than Classic)

Once all of these assumptions have been realized it is time to create the ASP.NET membership database that will house the FBA members and roles that will be needed for your SharePoint extranet.

Creating the Membership Database

The process for creating the Membership Database within the SharePoint 2010 environment is exactly the same as within SharePoint 2007. We are going to be using the ASP.NET SQL Server Setup Wizard.

1. On the SQL server navigate to C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regsql.exe application.
2. This brings up the Select a Setup Options window. Make sure that Configure SQL Server for application services and click Next.

1. Add the name of the SQL Server you are going to be accessing with the account information of the user with "Create Database" access.
2. You can either name the database or use the default, aspnetdb. Click Next.

1. Confirm the settings and complete the database creation.
2. Once the database has been created, make sure to grant the SharePoint Farm and SharePoint Content accounts appropriate access

• Open up the SQL Server Management Studio and open the Security node.
• Within the Logins make sure that the SharePoint Farm account is there, if not then Right-click on Logins and add the SharePoint Farm account.
• Make sure to go into the Properties for the SharePoint Farm account and on the User Mapping node sure that the aspnetdb is selected.
• If the SharePoint Farm is not the owner of the aspnetdb, then select all "aspnet_" access options and then click OK. (This is following least privileged security practices)
• Repeat steps b-d for the SharePoint Content Account.
         3.  Last thing before leaving SQL is to ensure that mixed authentication mode is enabled.
• Right-click on the Server in the Object Explorer and select Properties.
• In the Security node and Server authentication section make sure to select SQL Server and Windows Authentication mode.

Provisioning Claims Based Web Application

1. Close out SQL Server Management Studio and navigate to SharePoint Central Administration.
2. Click on Manage Web Applications link and in the SharePoint ribbon click on New.
3. Make sure to select the Claims Based Authentication radio button.

1. In the Authentication Type section select Enable Windows Authentication and select NTLM or Kerberos.

A choice needs to be made at this point. How are you planning on staging this SharePoint web application? Here are a couple of scenarios:

Scenario 1: Multiple zones are needed for this installation. The website is an internet web site and we are using FBA for users to log in and manage the content. Then it is suggested the following:

• Default Zone – Server Name with Anonymous and FBA setup.
• Internet Zone – Desired URL with only Anonymous setup.
• Intranet Zone – Specialized URL with only FBA setup. You could also add SSL to this if desired.

Scenario 2: Default zone needed for this installation. Intranet or extranet with outside members needing access so only using the default would be fine.

1. If you are using scenario 1 or 2 you are going to need to Enable ASP.NET Membership and Role Provider and enter in the Membership Provider and Role Manager names. These could be as simple as ACMEMembershipProvider and ACMERoleProvider. Whatever you choose make sure to document this for later use when configuring the web.config files.

In the next post I will talk about the fun task of configuring the web configuration files within SharePoint.

However before I get there, I need to make sure to recognize the website I found some vital information on the ASP.NET database. Thanks. http://donalconlon.wordpress.com/2010/02/23/configuring-forms-base-authentication-for-sharepoint-2010-using-iis7/

Stay tuned for the next exciting episode of When SharePoint FBA goes Bad!

There are different types of modalities when it comes to training for the organization. These include specific and guided training when needed, provide self-service resources for users and continue training with ongoing support and updates.  The wide range of training materials now available will assist City of Bloomington at fulfilling these requirements.

Modalities:

• Classroom Hands On – This type of training can be done internally of your organization or through a training company. If training is provided by a training company, the course should include hands on demo environment that is not the same as your internal SharePoint environment. Information provided in a training company course will be general to the overall feature set of SharePoint.
• On Line (Instructor Lead) – Similar to the Classroom Hands On, but participants watch the instructor via the web and will remote into a virtual environment to work on SharePoint.
• On Demand Video – This training gives flexibility to the participant on when they want to take the training. This utilizes some video sessions that are pre-recorded and available at any time. This type of training will usually not have any type of demo SharePoint environment available for use. This type of modality is essential for the continued maintenance of training after the initial training.

Within every organization there are different levels of instruction that will need to take place. This will range from general use of SharePoint to specific targeted training at the department or process level.

Training Levels:

• General SharePoint training – This training gives the participant training on how SharePoint works, terminology, etc.
• Organizational SharePoint training – This training provides information on organizational specific features within SharePoint. This may include specific forms, calendars, libraries or customizations that are built the organization’s SharePoint environment.
• Department/Division SharePoint training – Departmental specific modifications which can include metadata, processes, etc

Part of a good SharePoint implementation is the use of governance. Within the SharePoint governance stack are many different plans and policies that need to be addressed:

• Physical SharePoint Architecture
• Support & Maintenance
• Training
• Security
• Information Architecture
• Document and Content Management policies
• Communication
• Roles

Within this Role matrix you will find (these are some of the most common ones, within certain organizations you may find different roles to be accommodated):

Each one of these roles is extremely important in the overall scheme of a SharePoint deployment. But I would like make the suggestion that without proper representation by the business within the role of the SharePoint Site Owner the SharePoint implementation will flounder.

Word of warning! These features may change between Beta and release of Office 365. It has been rumored that features like the BCS, which is not available in SharePoint Online will eventually be added.