I was patching a SharePoint 2013 farm recently and all was going great while installing the CU’s on the servers. Once all of the patches were installed, I started to run the SharePoint 2013 Products Configuration Wizard on the first WFE server, which went without an issue. The second WFE server seemed to be running fine too, getting to step 9 out of 10. It was on this step for about an hour when I went home for the evening (this is a test environment). The next morning, it was still at the same stage.
Initially I reboot the server and tried again, but got the same results. To remedy this issue, I performed the following actions.
- Open services.msc
- Stop the SharePoint Timer Service
- Browse to C:ProgramDataMicrosoftSharePointConfig
- Open the folder with the newest date modified on it.
- Delete all files from the folder except for cache.ini
- Open cache.ini and change the number within to any random number ensuring it has the same number of digits as the original. I went with 12345.
- Run the following command from an elevated command prompt – Psconfig.exe -cmd upgrade -inplace b2b -wait -force
After that, the server was updated and ready to serve content again.
I ran in to an issue today that had my head battered for a good half an hour before turning to Google.
The issue involved opening documents, which happened to be in my SkyDrive Pro library, with Office Web Apps. The apps threw different errors, listed below;
Word Document : “Sorry, there was a problem and we can’t open this document. If this happens again, try opening the document in Microsoft Word.”
Excel Document: “We couldn’t find the file you wanted. It’s possible the file was renamed, moved or deleted”
PowerPoint: “Sorry, we ran into a problem. Please try again”
One Note:”Sorry, you don’t have permission to edit this notebook.”
After an hour of Googling and trawling through false positive results (thanks to Microsoft’s genius idea of keeping the “SkyDrive Pro” brand the same in hosted and on-premises SharePoint farms) I found a blog post (linked below) that shone some light on my issue. It also made me realize that the issue wasn’t local to SkyDrive Pro as well.
I turns out that the issue was down to the fact that I provisioned Web Apps using SSL, and the SkyDrive Pro library wasn’t using SSL. This caused OAuth not to function on the http site. Web Apps, being https, didn’t much like this and shit itself. Oh well.
The resolution is either to enable SSL on all SharePoint sites that Web Apps should be accesible in, or simply allow OAuth over http (detailed below.)
Run the following PowerShell script in SharePoint Management Shell on your SharePoint box(es.)
$config = (Get-SPSecurityTokenServiceConfig)
$config.AllowOAuthOverHttp = $true
Credit for this solution goes to ms_dynamics.
References: Office Web Apps 2013 and SharePoint Issue relating to SSL
The past few days I have had the pleasure of working with User Profile Sync in SharePoint 2010 and my observations follow.
1. It’s shit! – Although Microsoft have improved this feature of SharePoint with a series of CU’s, it is the most complicated part of SharePoint 2010 to setup, or at least the trickiest to troubleshoot.
2. It doesn’t like proxy servers – I struggled to get the UPS to start successfully for a full day. The log in ULS viewer was getting to “ILM Configuration: The ExportMiisEncryptionKey process completed successfully” before restarting the provision process. It turned out it was our automatic proxy configuration script that was causing the problems. To fix this I followed the steps below.
1. Hold Shift and Right-click Internet Explorer
2. Click Run as different user
3. Enter the credentials for your Farm account
4. G to Tools > Internet Options > Connections > LAN Settings and either disable the “Automatically Detect Settings” check box or add an exception for your SharePoint server
5. Reboot Server
3. User Profile Picture Import could be more seamless – OOTB SharePoint will import user profile pictures from AD. Unfortunately not many of the guides on the internet mention the fact that the import doesn’t create the required thumbnails automatically. This is a problem as the images in AD are stored as a blob and the “Picture” field in UPA is expecting a URL to the image. To fix this, run the following PS command (I had to login as the farm admin).
Update-SPProfilePhotoStore -CreateThumbnailsForImportedPhotos 1 -MySiteHostLocation http://mysitesurl
If you get a Null Reference exception when attempting to run this command, then you don’t have the permission to do so. This Technet article explains the permissions requirements for updating user profiles, along with a few other things.
All in all, this is a great product until it goes wrong, then it is an absolute beast!
I know all of this information is already available online, but the more times it is published the less time it will take for people to find it in Google 🙂
I ran into a very interesting error in SharePoint today and thought I would document it as I attempt to fix it. Hopefully it will help somebody else in the future.
In my site collection -> Site Actions – > Site Settings – > People and Groups I noticed that all of my groups were duplicated. If you try to click on one of the groups to edit it there is no issue, but the second group throws the following error.
I was actually going to delete a load of groups to start with, so I decided to delete them all and re-create the ones I need. Since I can’t get into edit the group in the GUI, I tried powershell on the server. This didn’t work either and bombed me out with the same error.
Now what? I decided to check Central Admin and take a look at the content databases. There appeared to be 2 site collections in the content database. I can only remember creating 1, although the site was migrated from Sharepoint 2007 so maybe that had something to do with it.
I then backed up the content database and restored it in our development environment to do a bit more digging. When you hover over the group name in SharePoint the URL has ID=### at the end. I fired up MS SQL Management Studio and took a look in the “Groups” table and noticed that the groups present had the same ID’s as the URLs for the groups displayed in SharePoint that I could still edit. There were no rows for the groups that I could not edit though. It looks like the groups have had their ID’s changed for some reason.
Then I edited the table and copied the row of a working group and inserted a new row, pasting from my clipboard and changing the ID to the ID in the URL or the group that was not working. I couldn’t commit this as the Title already existed in the bale, so I added a 1 to the end of the title for the row I had just created and committed it.
I went back to SharePoint and clicked on the group that was not working. It worked…. I could now click Settings – > Group Settings -> Delete and the group was gone, both from SharePoint and from the Groups table.
I seriously wouldn’t recommend this on a live server, but I repeated these steps in our development environment for each group and I was successful in deleting all of the groups from the SharePoint site collection.