Category Archives: Infrastructure

Solving the problem where Azure won’t delete your VHDs, storage containers and accounts

Are you unable to delete storage accounts, containers and VHDs in the azure portal? Even when you’ve already deleted the relevant Virtual Machines?

Maybe you’re running into the case that some of your VHDs are still configured as an potential disk for some Virtual Machine. Azure will place a lease on the VHDs in order to avoid accidental deletion.

On https://portal.azure.portal.com, you can’t see these configured disks. On https://manage.windowsazure.com/ you can though.

Go to the ‘Virtual Machines’ item and click in the ‘Disks’ tab at the top of the page. There you see and delete these configured disks

Setting up MySites in Central Admin and the error “An error has occurred in the claim providers configured from this site collection.”

I was busy configuring the User Profile Service through the link “Setup My Sites”. I couldn’t change anything on that page as it listed NT Authority\Authenticated Users; c:0(.s|true; in the box for “Read Permission Level” and was already printing the error message No exact match was found. using the peoplepicker through the little “Browse” icon showed the error An error has occurred in the claim providers configured from this site collection.

If you run into this error then you can try 2 things:
1) Configure an Alternate Access Mapping for Central Admin
2) Point your webbrowser directly at the server instead of the FQDN that resolves to it

Assume Central Admin running on port 555 of server xxxSP01 and DNS is configured to resolve portal.contoso.com to the server. When you access Central Admin through http://portal.contoso.com:555, then you’ll encounter this problem. If you use http://xxxSP01:555, then there’s no problem.

What to do when SharePoint managed account passwords are already expired

Suddenly your SharePoint installation stops working…
You’re seeing HTTP 500 errors even on Central Admin…
The ULS logs contains errors such as:
Unknown SQL Exception 0 occurred. Additional error information from SQL Server is included below. The target principal name is incorrect. Cannot generate SSPI context
This can happen when the various service accounts for SharePoint are no longer able to authenticate due to expired passwords. By default SharePoint wont proactively change that password even if AD policies require them to be changed. And, as admin you don’t even know what the old password is.

Firstly, you can see which service accounts are used by SharePoint using PowerShell’s Get-SPManagedAccount cmdlet. Use the ‘Active Directory Users and Computers’ tools to reset the password of those accounts to something you know.

Secondly, get Central Admin up-and-running:
RDP to the SharePoint Server
Open IIS Manager
Find the Application Pool that hosts Central Admin and open its advanced settings.
The ‘Identity’ row, lists which managed account is used for Central Admin. Hit the … button and enter the account and its new password
Restart the application pool
Central Admin should be available now. If not, try an IISRESET

Finally, use Central Admin to update the service accounts
Go to SharePoint Central Administration->Security->Configure managed accounts.
Click Edit on each account and do the following:

Select “Change password now”

Click “Use existing password”

Type the password, and then click OK

You might want to enable the option “Enable automatic password change” now. As this will avoid the problem from occurring again

Creating site collections in their own content database

Central Admin doesn’t allow you to choose in which Content Database to create a new Site Collection. With PowerShell its easy:

New-SPSite  `
    –ContentDatabase "WSS_Content_SecondDB" `
    -Url "http://portal.contoso.com/sites/MyNewSiteCollection" `
    -Template "STS#0"  
    -Name "SitecCollectionTest" `
    –Description "A Site Collection created in a separate Content Database"  `
    -OwnerAlias "CONTOSO\Gerben" `
    –OwnerEmail "gerben@contoso.com" `

Backing up Azure VMs with PowerShell

When experimenting in my lab environment I want to create a backup of the virtual machines. The following PowerShell script will do just that. I assume you’ve already setup your PowerShell to work with azure by doing the following:

Setup the Azure PowerShell cmdlets (see: http://azure.microsoft.com/en-us/downloads/)
imported your Publish Settings File (see Get-AzurePublishSettingsFile and Import-AzurePublishSettingsFile)
Defined which storageaccount to use with Set-AzureStorageAccount
Shutdown all the Virtual Machines

Import-Module Azure -ErrorAction Stop
$backupContainerName = "backups"
function Backup-Lab
{
    $vms = Get-AzureVM

    if (! (Get-AzureStorageContainer -Name  $backupContainerName -ErrorAction SilentlyContinue) )
    {
        New-AzureStorageContainer -Name $backupContainerName -Permission Off
    }

    foreach ($vm in $vms)
    {
        Write-Host "backing up machine: " $vm.Name
        $disks = @()
        $disks +=  $vm | Get-AzureOSDisk
        $disks +=  $vm | Get-AzureDataDisk

        foreach($disk in $disks)
        {
            $DiskBlobName = $disk.MediaLink.Segments[-1]
            $DiskContainerName = $disk.MediaLink.Segments[-2].Split('/')[0]
            Write-Host "disk: " $disk.DiskName
            #Start an asynchronous copy of the VHD to our backup destination
            Start-AzureStorageBlobCopy -SrcContainer $DiskContainerName -SrcBlob $DiskBlobName -DestContainer $backupContainerName -DestBlob $DiskBlobName
            #Wait for the copy to complete
            Get-AzureStorageBlobCopyState -Blob $DiskBlobName -Container $DiskContainerName -WaitForComplete
        }
    }

Making your SharePoint site available outside your own domain

A while back I created a small SharePoint test lab using Virtual Machines on Azure. I had a Domain Controller, a SQL Server and a SharePoint server. SharePoint was configured to host on portal.contoso.com. All machines were part of the same Virtual Network I defined in Azure.

I was able to access the sites from each of the machines within the Vnet. However I didn’t want to RDP into a server machine just to access my SharePoint sites. After setting up the azure end-point I eagerly entered the URL xxxxxxxx.cloudapp.net but was presented with a standard IIS welcome page and not my SharePoint portal.

IIS 8 Standard Welcome Page

So what’s up with that? Obviously the web browser is able to communicate with the IIS on the SharePoint server, but its not serving up the SharePoint site. The issue here is that IIS has multiple sites hosted on a single IP/Port combination and it decides which one to serve up based the Host Header that the browser includes in its request. When I’m using the browser on my server it sends portal.contoso.com as host header, but from my home machine it will send xxxxxxxx.cloudapp.net as host header which IIS doesn’t recognize.

This is how I solved it:

using the Microsoft Azure portal, create two new Windows Azure endpoints that map between the internal ports for your site and Central Admin to the external ports on your Azure DNS name (xxxxxxxx.cloudapp.net)

Windows Azure endpoints for the SharePoint machine

Log on to Central Admin, go to Manage Web Applications and click on the web application that you want to make available
managing Web Applications in Central Admin

Now Click on the Extend button in the Ribbon and fill in the port, hostheader and URL (way down at the bottom, not shown in screenshot):

Extending the web application to the internet zone
In my case I didn’t change any of the authentication options as I did not want to grant anonymous access to the sites. If you do want this, then this is the place to do it

Don’t panic if Central Admin doesn’t show an extra web application. If you open up IIS Manager, you’ll see it

Managed navigation and the “A Default Managed Metadata Service Connection Hasn’t Been Specified” error

So, you’ve decided to enable managed navigation and when you press the “Create Term Set” button you get the error: Failed to Create Term Set: A Default Managed Metadata Service Connection Hasn’t Been Specified

This is occurs when your environment is running Managed Metadata Service and has one or more Managed Metadata Service connections, but none of them have enabled the setting This service application is the default storage location for column specific term sets.

Your new SharePoint site isn’t accesible from the server, but it works from other machines.

You’ve just installed and configured a SharePoint server and you fire-up IE on the server to see if everything works…..Oops, IE keeps asking for your credentials and eventually returns a HTTP 401. Then you notice that the sites are accessible from other machines. In this case you’re running into a security measure called the loopback check security feature. See http://support.microsoft.com/kb/896861 for the details.

Here’s how to disable the check just for your specific sites on that machine with a short PowerShell script:

$sites=@(
    "portal.contoso.com",
    "my.contoso.com"
)
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" -PropertyType MultiString -Name BackConnectionHostNames -Value $sites

Here is how to completely disable the Loopback check on Windows using a single PowerShell command:

New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name DisableLoopbackCheck -Value 1 -PropertyType DWORD

Gerben’s blog

Musings on software development and quality assurance