I was setting up a Report Server for our SharePoint 2010 Farm this morning and I ran into a show stopper. After installing SharePoint 2010 on the new server and getting it ready, I ran the SharePoint Products Configuration Wizard only to get to the PassPhrase step and be told I was entering the incorrect passphrase.
I have it written down from the original setup and I was positive it was correct, but no matter what I tried I couldn’t get it accepted. So I did a quick look-up on how to recover it. Turns out you can’t. Fortunately, you can change it without knowing the old one or requiring any downtime for your farm.
I was recently helping a user with their SharePoint site on their machine and I noticed some weirdness with the ribbon display. The Tab names were all truncated and too small and their User Name (Menu) was not showing in the upper right corner. Obviously, this concerned me.
Some quick searching didn’t turn up anything and I couldn’t reproduce it on my end. Then 2 days later I was helping someone else and they had the same display problems. Checked their version of IE and they were exactly the same (8.0.6001.18702CO)! But I believe the problem can happen with any version of IE 8.
With this new information did another quick search and found this quick article from Microsoft: http://support.microsoft.com/kb/2062185 where they indicate the Zoom feature is causing the problem.
Sure enough, adjusting the zoom back to 100% fixed the display issue. Strangely, IE 8 seemed to be handling zoom levels in increments of 10 just fine (110%, 120%, etc.) but custom zoom levels (like 128%) freaked it out.
This is problematic because it looks like a problem with the site and adjusting your zoom level is as easy as holding the CTRL key while using the middle mouse scroll. I found that I couldn’t reproduce the problem with IE 9. Until we can get everyone upgraded (a major process around here), it’s just a matter of education among our support staff and end users.
A common requirement/feature of sites is to have a Frequently Asked Questions (FAQ) section. This is a quick and easy way to provide help to end users. A FAQ is nothing more than a series of questions with their answers.
This can be implemented in a variety of ways but the standard way is to have the question above the answer all on a single page. This isn’t always the best way, but it’s certainly the most common and recognizable way.
Fortunately SharePoint makes this really easy using a custom list and only takes about 5 minutes to setup. This can be done in SharePoint 2007 or 2010 in both MOSS/Server and WSS/Foundation. Here’s the steps:
Create a custom list. Name it FAQ or something.
Edit the Title column and rename it Question.
Add a new Column of type Multi-Line Text and name it Answer
Modify the default view to only show those 2 columns and set the style to Newsletter.
That’s it! You end up with something like this:
You can then place this on a page using a ListView Web Part or just link directly to the main view. WOWEE!
Want to get fancy? Add another column called Order of type Number and use it to set custom ordering values and just sort by that column in your view.
We recently upgraded to SharePoint 2010. Things went relatively smoothly, but we began to experience problems with some of our Office users. I looked everywhere but I couldn’t find anything that described our problem perfectly or that provided a solution. So here is the guide I wish we’d had before we called Microsoft Support.
Windows 7/Vista machines had missing/broken links to the sites within the SharePoint Sites library on their machine. These were all users with MySites most of whom had had no problem opening and saving documents directly within Office to SharePoint 2007. This was affecting both Office 2007 and Office 2010 users.
Sometimes there was a MySite link, sometimes just a Member Sites folder, sometimes neither and sometimes various levels of Member Sites with the wrong type of Icon (Not like shown above). Some users could connect fine although it was very slow, others would have some very strange issues.
In addition to constantly asking for authentication or telling them access was denied to their own MySite, there were users who seemed to be saving their documents nowhere. Checking the Upload Center would show they did save them but not as expected.
For instance, one guy added his personal documents library to Office using the Connect To Office button on the SharePoint Ribbon. Trying to save a word document he double clicked on this link within the SharePoint Sites Library and everything saved. Further investigation with SharePoint Designer showed that their was a word document at his MySite root named PersonalDocuments.aspx.doc!
Obviously these links were broken. Sometimes they were gone from one day to the next and this was causing a lot of frustration. We tried messing with the registry entries, checking our version of Office, verifying access was setup correctly and finally gave up and called Microsoft Support.
We had had a SharePoint 2007 farm using Windows Authentication. We built a new SharePoint 2010 farm and used the Database Attach upgrade approach. The new farm was built to use Kerberos authentication. When everything was good to go we switched the DNS entries to the new farm and voila, everything worked! (Obviously excluding the weird Office problems).
Our clients are mostly XP machines running Office 2007 – these had no issue. The Windows 7 clients running both Office 2007 and Office 2010 began experiencing the problems even though everything worked fine with SharePoint 2007.
Our DNS entry for SharePoint was set to the FQDN (ie sharepoint.something.something). Although alternate access mapping was setup for just the sharepoint portion, the FQDN is the only public url. This turned out to be the problem.
In summary, the Web Client service uses Windows HTTP Services (WinHTTP) to do network operations behind the scenes (including requesting the list of Member Sites and MySite urls to update your SharePoint Sites Library). WinHTTP only sends user credentials in response to requests that occur on a local intranet site.
So just add your site to the Trusted Sites list and you’re done! Just kidding, that’s far too easy! WinHTTP does NOT use the security zone settings in Internet Explorer to determine if it should send the credentials. Instead it uses some pretty basic logic:
Are there any periods in the server’s name? Nope: must be local – send them credentials! Yes: Eeeek! Evil Internet, no credentials for you!
So if you happen to be using a FQDN or anything else with periods in the address, unless you’ve setup a local (no perioded(?)) proxy, no authentication is gonna happen which is pretty problematic for nearly every use case in SharePoint.
A hotfix is available for Vista and was included in Windows 7. But the hotfix doesn’t fix the logic nor does it start using the security zone definitions from your internet options. It provides a registry configuration of trusted sites (see solution below).
Testing the Problem:
Office only requests this list of sites/libraries once every 24 hours or so based on a registry key. However, following the steps below you can get it to make the request(s) again. In order to watch them, download and install Fiddler. You should be able to see all the requests as it makes them.
Close all Office programs (including Outlook)
Using RegEdit, delete the LinkPublishingTimestamp registry key.
Vista and Above: