The correct way to do it is the following:

Get-SPDeletedSite

This will give you an overview of the sites that are deleted but still  "out there".

The property we are interested in is the site id.

Now create the content database object:

$webapp = Get-SPWebApplication https://myawesomesite.koentoso.com

$cdb = $webapp.ContentDatabases.Item(0)

Then we will force the delete of the site with the id from the previous command Get-SPDeletedSite.

$cdb.ForceDeleteSite("8da556e0-264f-483b-a2b0-3fb1f8e33573",$false,$false)

Now you should be able to restore your site collections without any issues.

https://technet.microsoft.com/en-us/library/jj219613.aspx

Strangely, it refused to start and went back to the services page. In the end, the following powershell fixed the distributed cache (after we re-added the spserviceinstance)

$instanceName ="SPDistributedCacheService Name=AppFabricCachingService"
$serviceInstance = Get-SPServiceInstance | ? {($_.service.tostring()) -eq $instanceName -and ($_.server.name) -eq $env:computername}
$serviceInstance.Unprovision()
$instanceName ="SPDistributedCacheService Name=AppFabricCachingService"
$serviceInstance = Get-SPServiceInstance | ? {($_.service.tostring()) -eq $instanceName -and ($_.server.name) -eq $env:computername}
$serviceInstance.Provision()

The solution in our case was to reboot the server and the domain trust was sorted. Afterwards all issues were sorted and the farm was succesfully expanded :-)

Microsoft.Crm.SharedSetup.SetupException: The XML in the configuration file is not valid. Location: F:\InstallConfigWebFrontEnd1.xml. Please fix the configuration file, and then try again. --->
System.UriFormatException: Invalid URI: The format of the URI could not be determined.
at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
at Microsoft.Crm.Setup.Server.ConfigurationParser.ParseWebsiteSettings(XmlNode element)

As the error message states, one would check the XML file in every way to see if we did not mess up anything. In the end, we did not find anything wrong with it. What did give us a hint though, is the following part of the stacktrace:

at Microsoft.Crm.Setup.Server.ConfigurationParser.ParseWebsiteSettings(XmlNode element)

This means that something is going wrong once the setup tries to set the website from the following XML tag:

<WebsiteUrl Create="false">Default Web Site</WebsiteUrl>

After checking every possible option with the tags, we checked the IIS. For some reason IIS was missing it's default web site, therefor it could not use the Default Web Site during setup. Changing the script to

<WebsteUrl Create="true" port=80>Default Web Site</WebSiteUrl>

made setup run fine.

Right click on your network connection (which should show with a red cross on the right bottom corner)

Open network and shareing center

Click on change adapter settings.

Rightclick your wi-fi adapter and select properties

Select configure

Select the power management tab and untick the box if it is ticked.

After this, your wireless will still show as off. Even using the function keys to turn wireless on and off will not get you there. Press the windows key and type wireless

Select settings and then choose the option Turn Wireless On or Off

And there, you will see that the wireless is off. Put it to status on.

I’m not the only one who experienced this problem. And this fix seems quite easy. For some reason the wireless on / off key on the keyboard doesn’t seem to properly enable the wireless.

This is the nice screen I got when I wanted to finalize the configuration of a blank SharePoint 2013 development environment at the customer that was already “partially prepared”. Even if I was quite sure I checked those to see if they were running. I checked again:

Looking in the Manage Services Screen:

Going to System Settings – Manage Services on this Server

Seems like everything is running. So where does this come from? As I am so used to follow the Technet blog post (and that this step is a little bit less obvious when fastscrolling through the page), it took a while to realize we are missing a service application. Even though the Subscription Settings Service is running, there is no corresponding Service Application. This service application can only be created in PowerShell:

Get-SPManagedAccount COMICS\spsap.dev
$appPool = New-SPServiceApplicationPool -Name SubscriptionServiceAppPool -Account $account
$serviceApp = New-SPSubscriptionSettingsServiceApplication -ApplicationPool $appPool -name "Subscription Settings Service Application" -DatabaseName "SP2013DEV-SubscriptionSettingsDB"
$serviceAppProxy = New-SPSubscriptionSettingsServiceApplicationProxy -ServiceApplication $serviceApp

Once this is done, you should see it pop up in your service applications:

Now we are able to set up our app domain