Disable site collection upgrades after migrating from SharePoint 2010 to 2013

When migrating SharePoint from 2010 to 2013, it depend of the migration strategy you choose how the end result will appear for your end users. Two different approaches when migrating to SharePoint 2013 can be:

  1. Migrate the farm, content and solutions from 2010 to 2013
  2. Migrate the farm to 2013, but keep the content and solutions in 2010-mode

Selecting the last approach requires the least effort, and could be preferred for several reasons:

  • Reduce the scope of the migration to only include the farm. Less risk and effort needed.
  • Migrate content and solution in a later stage after the new 2013 farm has been stabilized.
  • Keep solutions who will have an end-of-life in near future without extra effort to migrate it.
  • Customer has no functional requirements to adopt 2013 functionality at the current time for all or parts of the solutions, and only requires a platform upgrade.

Since the site collection administrators can on their own effort start the upgrade of their site, I will cover how to get control of this process by disabling the site collection upgrades. As an farm administrator you can then later re-enable this feature, or perform the migration on behalf of the owners (maybe preferred)-

How will a upgraded site collection in 2010-mode appear?

When visiting a site collection after the platform has been migrated, pretty much nothing has changed (good!) for the end users, except a light pink (not nice!) bar at the top reminding us that this site should be upgraded.

site collection upgrade 1

On the site collection upgrade page, an option to “Try a demo upgrade” is available. By default this request is put into a queue, and processed once each night. A copy of the site collection is created, and the site owner will receive an e-mail with the URL. After a fixed time of 30 days, the test site will be deleted.

The reason why this is running by night, is by my best guess because the source site will throw an error while the creation of the eval site runs. So don’t be too tempted to run this timer job manually if the site is in use!

The messages on the top of the screen will only be visible to the site collection administrators, so the regular users (visitors, members or owners) will not see this at all.

Disable the self-service evaluation

In the “SharePoint 2013 Management Shell” run the following Powershell script.

$siteUrl = "http://sp2013"; # Change this one!
$site = Get-SPSite $siteUrl;
$site.AllowSelfServiceUpgradeEvaluation = $false;

The option to create a evaluation site is no longer available for the site collection. The next step would be to disable the possibility for the site owners at all to perform the upgrade them self.

site collection upgrade 2

Disable the self-service site collection upgrade

In the “SharePoint 2013 Management Shell” run the following Powershell script.

$siteUrl = "http://sp2013"; # Change this one!
$site = Get-SPSite $siteUrl;
$site.AllowSelfServiceUpgrade = $false;

Now both the options are disabled, and the pink bar at the top of the site is also removed.

site collection upgrade 3

What if I want to disable this on all site collections?

If you want to go all-in, this Powershell script disables both the evaluation site and self-service upgrade for all site collections within a web application:

$webAppUrl = "http://sp2013"; # Change this one!
Get-SPSite -Limit All -CompatibilityLevel 14 -WebApplication $webAppUrl | % { $_.AllowSelfServiceUpgrade = $false; $_.AllowSelfServiceUpgradeEvaluation = $false; }

Summary

In this article we have seen how a site collection appear to the end-users after the farm has been migrated from SharePoint 2010 to 2013, and the content databases attached back on. With a few lines of PowerShell the administrator can disable both the ability to evaluate a upgraded site as well as perform the self-service upgrade.

Preparing a new server with Windows Server 2012 for development and testing

As a SharePoint developer, I am quite often required to set up new servers for development and testing. Every time I set up a new server, I do a basic configuration before I start installing the specific software I need (SQL Server, SharePoint, Visual Studio etc.). The purpose of doing these preparations is to enable a more desktop like user experience, and remove unnecessary interruptions in the day-to-day usage.

This guide is based on a Windows Server 2012 Standard GUI installation.

Basic settings in Server Manager

After the initial installation and first time password setup is complete, continue in the Server Manager by setting these basic settings to get started. Select Local Server in the left side menu.

  1. Change computer name (postpone reboot to later)
  2. Enable automatic windows update (and start first time check)
  3. Disable IE Enhanced Security (for all users)
  4. Change timezone

server-manager-overview

Add “Desktop Experience” role

This feature adds some settings and software to make the server feel more like a standard Windows 8 end-user computer.

In the Server Manager select Manage and Add Roles and Features.

server-maanager-add-role

In the wizard, select Next until you reach the Feature step. Locate User interfaces and infrastructure and expand it. Check the option for Desktop Experience.

server-manager-desktop-expereince

Enable remote desktop connections

All my installation are mostly on virtual hosts, so getting Remote Desktop up and running is a much better experience than the build in console in for example Hyper-V.

Under Settings (search for the words), select Allow remote access to your computer.

remote-desktop-allow-users

Then select Allow remote connections to the computer.

remote-desktop-allow-users2

Disable password expiry

Disabling these policies is not a good idea in general, but in a development environment, this is necessary to avoid hassle with Windows nagging about setting new passwords from time to time. I always use a general password for these environments, and want to avoid it being changed somewhere.

Open Group Policy Management (just search for it). Right click on Default Domain Policy and select Edit.

disable-password-policy-1

Open the path Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Account Policies -> Password Policy.

disable-password-policy-2

Set Enforce password history and Maximum password age to 0. Disable the Password must meet complexity requirements.

Disable shutdown event tracker

The shutdown event tracker is fine for a server, but is unnecessary on a development machine.

disable-shutdown-event-tracker-3

Open Group Policy Management (just search for it). Right click on Default Domain Policy and select Edit.

disable-shutdown-event-tracker-1

Open the path Computer Configuration -> Policies -> Administrative Templates -> System. Select Display Shutdown Event Tracker.

Select Disabled to avoid this dialogue to appear the next time you shut down the server.

Enable execution policy for PowerShell

By default PowerShell script are disabled from being executed, and a policy setting must be set.

Open a PowerShell Console (as Administrator) and type Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

powershell-set-executionpolicy

Also just as a remined make sure that script you try to execute aren’t blocked. Check this by right clicking the file, select Settings and check if the button Unblock appear in the bottom right of the dialoge.

Disable Loopback check with PowerShell

This is mainly for servers that will be used for hosting web applications with IIS. For more details see: http://support.microsoft.com/kb/896861

Open a PowerShell Console (as Administrator) and type New-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa -Name “DisableLoopbackCheck” -Value “1” -PropertyType dword

powershell-disable-loopback-check

A reboot will be necessary for this setting to take effect.

Summary

In this article a step-by-step guidance for preparing a Windows Server 2012 for development and testing use were presented. This enables a better user experience when working in a server environment on the day to day basis.

Just as a disclaimer, these steps reduce the general security level normally required on a server, and should only be used for development and testing purposes.

Any tips that could be included in this preparation guide, are welcome!

Installing workflow service for SharePoint 2013 Preview

The workflow service in SharePoint 2013 Preview is no longer a part of the standard SharePoint server installation, and is provided by the Windows Workflow Manager (Azure). The service it self is a huge improvement to the product, but requires additional step as it has to be installed and configured post-installation of SharePoint Server 2013.

Getting the workflow service in SharePoint 2013 Preview up and running on my development environment gave me some challenges that wasn’t well documented at the time, so I decided to list some of the error messages and steps that helped me getting it up and running properly.

Installation and configuration

I started my installation by following this documentation on TechNet:

Installation guide for Workflow Manager 1.0 Beta: http://technet.microsoft.com/en-us/library/jj193478

Configuration guide for connecting SharePoint 2013 to Workflow Manager: http://technet.microsoft.com/en-us/library/jj658588(v=office.15)

Error messages

  • Configuration wizard: Could not successfully create management Service Bus entity ‘WF_Management/WFTOPIC’ with multiple retries within timespan
  • Browsing the WF management site (http://localhost:12291/):”Object reference not set to an instance of an object”
  • Powershell: “The trusted provider certificate which is already in use.” or  “Unable to properly communicate with the workflow endpoint”
  • Service App error (/_admin/WorkflowServiceStatus.aspx): “SharePoint was unable to communicate with the Workflow host”

Tips for troubleshooting

  • Check which regional settings are used on your setup and admin account. When I used something else than “English (United States) I got an error when accessing the configuration database.
  • Remember to start SQL Server Browser, and keep it to start automatic.
  • Grant the workflow service account the server roles “dbcreator” and “securityadmin” in SQL Server.
  • Grant the workflow service account local administrator rights on the server.
  • Run the workflow configuration wizard logged in as the workflow service account.
  • Use a FQDN for the account in the configuration wizard (default suggestion is wrong).
  • To clean up a failed installation:
    • Run workflow configuration wizard, and remove the server from the workflow farm.
    • Manually delete the databases created (prefixed with Wf and Sb in default installation).
    • If registered with SharePoint, remove the service application “App Fabric Application Proxy”.
  • It is possible to run the registration with SharePoint, Register-SPWorkflowService, with a “-Force” switch to get pass a state where it tells you it already has been registered, but still fails.

Summary

This article gives some tips for resolving different errors occurring either when installing the workflow service, or when connecting it with SharePoint.

DISCLAIMER: SharePoint 2013 is in preview at the time this article was written. When the product reaches RTM the content of the article may not be relevant or wrong.

Setting up internet access for Hyper-V with NAT in Windows 8

In my work with development of SharePoint solutions, I heavily rely on virtualized environments on my own laptop computer. Working inside virtualized environments complicates the configuration of your own infrastructure, and to get and acceptable user experience inside the virtual machines a working internet connection is a requirement.

Earlier Hyper-V was only supported on the server OS, but from Windows 8 this has also been added to the client OS as well.  Since I run this on my laptop computer, connected to different networks from time to time, it gives me some other requirements for the internet access than traditional fixed location Hyper-V setups. Setting up an external virtual network switch could give me internet access, but also connects the virtual machine directly to the host network. Exposing the virtual machines on the host network has many disadvantages, so setting up a NAT’ed solution where they are hidden behind the host computer’s network connection would be a better solution to me.

Creating a new virtual switch in Hyper-V

Start by opening the Hyper-V Manager, and locate the  Virtual Switch Manager in the Actions menu.

Create a new virtual network switch by selecting New virtual network switch, give it a name (in this example “Shared”) and select the connection type Internal.

Configure internet access for the new virtual switch

The next step is to share your current internet connection on the host with the newly created virtual network switch in Hyper-V.

Open Control Panel -> Network and Internet -> Network Connections.

Right click on your connection who has access to internet (in this example “Wi-Fi”), and select Properties.

Select Allow other network users… and select the newly created virtual network switch (prefixed with “vEthernet”). The name in this case is the save as entered as name for the virtual network switch, in this example “Shared”.

After selecting OK the virtual network swich will get a static IP of 192.168.137.1, and serve as a DHCP server within that range for the virtual machines.

Enable internet access on virtual machines

In Hyper-V Manager, select a virtual machine and Settings from the menu. Make sure the virtual machine is powered off first.

Choose to add new hardware, network adapter and select the newly created virtual network switch. Power on the virtual machine, and a new network adapter with NAT’ed internet access should appear. The adapter should have been assigned a dynamic IP-address from the 192.168.137.x range.

Summary

In this walk through we have seen how to configuring NAT’ed internet access for virtual machine in Hyper-V. Even if this guide was created for Windows 8, most of the steps can be applied both on Windows Server 2008 R2 and 2012 with the same result.

Exporting profile pictures from SharePoint 2010 to Active Directory

Profile pictures can either be stored in Active Directory or in SharePoint. The main reason for placing the profile pictures in SharePoint is for easier management, self-service and maintaining high quality images. Storing the pictures directory in Active Directory gives some restrictions on both physical file size and pixels.

Set up delegation in Active Directory

Select “Delegate Control” on the top level in Active Directory. Locate the system account performing the synchronization.

Choose “Create a custom task to delegate”.

Choose “Only the following objects in the folder” and “User objects”.

Choose “Property specific” and “Read thumbnailPhoto” and “Write thumbnailPhoto”.

Finish the wizard and the delegation should be fine.

Set up export in SharePoint User Profile Service

Locate the user profile property named “Picture” in the user profile service application in Central Administration.

Edit the property and set up an export to the Active Directory field “thumbnailPhoto”.

This should appear like this after choosing “Add”.

Run a full synchronization of the user profiles.

To verifiy the result we have updated the profile picture of one user, and browsing the status in the MIIS Client show that the picture was successfully exported for the user.

Known issues

This can give an error message “permission issue” when checking the status in the MIIS client (C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\UIShell\miisclient.exe).

This error can appear when the system user running the synchronization haven’t been delegated the necessary permissions in Active Directory as described in the beginning of this post.

Summary

After successfully setting up a synchronization of profile pictures from SharePoint to Active Directory the images can be used throughout the company in other applications like Lync and Outlook.