The only catch is your IPad needs to have the iOS 5 Safari browser.

More info about how to correctly configure the views can be found on TECHNET: http://technet.microsoft.com/en-us/library/hh697482.aspx

One of the prerequisites is that the Lync 2010 Cumulative Update 4 needs to be installed. Besides the installation of the Lync 2010 CU (November 2011) there are a few more changes that needs to done before the mobility service works. These changes relate to:

1. Certificates
2. DNS records
3. Reverse Proxy

Click on the links to download either the software or the guides:

Microsoft Lync Server 2010 Mobility Guide.

Microsoft Lync Server 2010 Mobility Service and Microsoft Lync Server 2010 Autodiscover Service.

Lync 2010 for WindowsPhone7

This means upgrading will be faster!

More information can be found on the Microsoft SharePoint 2010 Update page on TechNet.

The download of the August 2011 CU can be found here:

• SharePoint Foundation 2010 (KB253050)
• SharePoint Server 2010 (SPF + SPS CU) (KB253048)
• SharePoint Server 2010 with Project Server 2010 (SPF + SPS + Project Server CU) (KB253049)

The SharePoint Diagnostic Studio will be part of the upcoming release of the SharePoint Admin Toolkit next month. It could check for several statistics within the SharePoint farm including: latency checks, capacity planning and trends. Several reports will be included like basic reports, performance reports, availability reports and usage reports. There is also an integrated search and snapshot + export abilities.

Take a look at the interview with Bill Bear on YouTube:

SPSRedmond–Bill Bear

I found that a bit odd, because for several months my SharePoint 2010 deployments are done using PowerShell and every time the User profile Synchronization service started nicely. The first thing I did was opening the ULS viewer and sorted to Category – User Profiles. The ULS viewer than presented me this error:

ILM Configuration: Error ‘ERR_CONFIG_DB’

In and effort in solving the problem I read (again) Spence Harbars blogs: Stuck on Starting & Rational Guide to implement SharePoint 2010 User Profile Synchronization. The error I got is mentioned by Spence and is caused due to insufficient privileges of the SharePoint Farm Account on the Profile Sync DB.

So I went to my SQL Management Studio and looked at the privileges of the SharePoint Farm Account on the Profile Sync DB. I was a bit surprised to see that the SharePoint Farm Account had the correct privileges.

So if I had the correct privileges and my PowerShell script had never failed before, why now?

After searching for quite some time I found the solution to my problem!

As a best practice we created a SQL Alias, so nothing new about that. It turns out that MIIS, when configuring the Profile Sync DB, problems has when naming the SQL Alias as the instance name.

So when you got SQL server\Sharepoint and an alias as Sharepoint, the User Profile Synchronization Service would not start. When I used SQL server\instance name, the service started within 200 seconds.

The only solution here is to use PowerShell in order to assign the certificates.

So I executed the PowerShell commands needed for assigning the certificates:

The certificates were assigned but I received a warning, it turned out that the certificate chain couldn’t be verified. After fixing that part everything started up nice and the database synced with the rest of the lync servers.

After doing some digging I noticed also an event in the eventviewer:

Opening the log file as mentioned in the event, it turned out I had something to do with an duplicate entry in the applicationhost.config.

As stated in the error it had something to do with a duplicate entry at line 421. Opening the applicationhost.config learned that line 421 didn’t had anything to do with lync. The trick was to find OCSAuthHelperModule:

<add name="OCSAuthHelperModule" image="C:\Windows\Assembly\GAC_64\Microsoft.Rtc.Server.WebInfrastructure\4.0.0.0__31bf3856ad364e35\Microsoft.Rtc.Server.WebInfrastructure.dll" preCondition="integratedMode,runtimeVersionv2.0,bitness64" />

After deleting this entry, the installation went perfect!

Strange thing to me was that there was no uninstall option available via the control panel. A quick search provided me with this link to TechNet:  http://technet.microsoft.com/en-us/library/bb124004.aspx

So I copied the code and filled in the missing pieces, but nothing happened. Searching through the internet didn’t provide me with the right answer, some suggestions appeared correct….

After some trail and error I found the right solution to uninstall the UM language pack! The answer was:

1. Mount the Exchange DVD

2. Open a command prompt

3. Navigate to the Exchange DVD drive letter

4. Give the following command: Setup.com /RemoveUmLanguagePack:nl-NL

Apparently you don’t need the extra input for uninstalling after all, as suggested by TechNet. 

My customer had already deployed excel services and reporting services, they couldn’t however get PowerPivot to work. It was the first time I actually needed to install PowerPivot for SharePoint 2010. I remembered that PowerPivot came with SQL 2008R2, so I fired up the setup and installed PowerPivot. During the setup of PowerPivot it asked me if it was a new server or an existing farm. Since SharePoint had already been deployed I choose existing farm. When the setup ended I was looking at a failed installation.

Next thing I did was heading to technet and discovered that this was a known issue! A solution for the known issue can be found here. After solving the issue the installation went smooth and finished without errors.

Next step was to provide users with a PowerPivot site.

Before you can deploy a PowerPivot site you need to deploy the PowerPivot solution to you web application!! It seems that the setup only deploys to the Central Admin.

After a while some test users complained that they couldn’t view or edit documents. When trying to view or edit documents a nice popup box appeared with a correlation ID.

To troubleshoot this problem my first thoughts were that something went wrong with the installation. So I went to the Deploy Office Web Apps page on Technet. (http://technet.microsoft.com/en-us/library/ff431687.aspx#bkmk_underst). Reading through the document, it became clear that the installation went exactly as described on the page. There is a troubleshooting FAQ at the end of the deployment page, but nothing applied.

My next move was diving in to the eventviewer, I found one event regarding to this problem. The event stated that the Service Application Pool account didn’t had dbowner permissions on the content database were the site collections reside. After giving the account dbowner on the Content database on SQL the problem was solved.

So it turns out that when you setup SharePoint with multiple accounts and deploying Office Web Apps that you need to give dbowner permissions for the Service Application Pool account. Todd Klindt has a nice blog about which service accounts can be used to setup a SharePoint farm. Todd also mentioned the dbowner role for the Service Application Pool Accout. Here is the url to Todds blogpost: http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=237