This project has moved and is read-only. For the latest updates, please go here.

Deployment stalls "Creating Metadata Service Application..."


I have been building out an all-on-one-machine 2013 farm (DNS, AD, SQL 2012, SP 2013). My procedure is to make a little progress and take a VMWare snapshot. I got my system to the point where I could use ASPI v3.2 to complete the basic SP 2013 install. Then I ran into a scenario that I have reproduced twice.

The difference between my successful attempts and the failed attempts was installing the SP2013 pre-requisite EXEs but having ASPI install the hotfix patches. I was able to get around this by rolling back to my previous snapshot (without pre-requisites at all) and having ASPI complete all the prerequisite installs (much slower of course).

The script finally stalls with the following:
  • Provisioning Managed Metadata Service Application
  • Creating SharePoint Hosted Services Application Pool...
  • Starting Managed Metadata Service:
  • Starting Metadata Service Instance...
  • Waiting for Metadata service...Online
  • Creating Metadata Service Application...
The section of the install that deals with pre-requisites looks like this:
  • Installing Prerequisite Software:
    • Running Prerequisite Installer (online mode)........Done.
    • Prerequisite Installer completed in 00:00:25.
  • SharePoint 2013 "missing hotfix" prerequisites...
  • Checking for KB2554876...Already installed.
  • Checking for KB2708075...Already installed.
  • Checking for KB2472264...Already installed.
  • All Prerequisite Software installed successfully.
I know using ASPI for SP2013 is beta - but I thought I would raise the awareness of the behaviour.



csyvenky wrote Mar 12, 2013 at 4:48 PM

After three more failed attempts with varying configurations I should retract this assessment. Further attempts have failed in exactly the same way, but I have restored a snapshot that pre-dates the inclusion of the SP2013 pre-requisite installs.

There is clearly a bug in and around the area of the process where the Metadata Service Application is created. I just need to find it...

brianlala wrote Mar 15, 2013 at 4:59 AM

I experience this issue as well, on about 1 out of 5 attempts or so. Not sure what's happening, but my plan is to grab & analyze the ULS log output from around the time that it happens. Stay tuned...


wrote Mar 15, 2013 at 5:00 AM

csyvenky wrote Mar 15, 2013 at 4:29 PM

Here's what I know. I've not had this exact same failure in another multi-tier environment - twice. The last crash/freeze yielded the following:

On the database - seems normal:

Date 3/14/2013 9:47:06 PM
Log SQL Server (Current - 3/9/2013 5:05:00 PM)
Source spid69

Setting database option AUTO_UPDATE_STATISTICS to OFF for database 'UAT_MetaData'.

Date 3/14/2013 9:47:06 PM
Log SQL Server (Current - 3/9/2013 5:05:00 PM)
Source spid69

Setting database option AUTO_CREATE_STATISTICS to OFF for database 'UAT_MetaData'.

Date 3/14/2013 9:47:05 PM
Log SQL Server (Current - 3/9/2013 5:05:00 PM)
Source spid69

Setting database option AUTO_CLOSE to OFF for database 'UAT_MetaData'.

According to PSCDiagnostics.log there was an IIS reset just 10 minutes prior to the crash/freeze.

03/14/2013 21:37:28 8 INF Starting process C:\Windows\system32\IISReset.exe and waiting 300000 for it to stop

The last entries I have in the ULS are indicating psconfig had an exception.
03/14/2013 21:36:45.47 psconfig.exe (0x04B8) 0x0C88 SharePoint Foundation Health 8fvj Unexpected The health rule contained in Microsoft.SharePoint.Administration.Health.SiteDataServersTest could not be registered. A file with the name Dedicated crawl target configuration has one or more invalid servers. already exists. It was last modified by coryadmin on 3/14/2013 3:30 PM.
03/14/2013 21:36:45.49 psconfig.exe (0x04B8) 0x0C88 SharePoint Foundation Topology 8xqz Medium Updating SPPersistedObject SPUpgradeSession Name=Upgrade-20130314-213604-195. Version: 9635 Ensure: False, HashCode: 64219123, Id: 98e57abe-3d88-4cde-ace1-1862f8f59622, Stack: at Microsoft.SharePoint.Upgrade.SPUpgradeSession.Update() at Microsoft.SharePoint.Upgrade.SPUpgradeSession.ProgressUpdateEventHandlerMethod(Object sender, SPProgressUpdateEventArgs args) at Microsoft.SharePoint.Upgrade.SPManager.InplaceUpgradeAdministrationWebApplication() at Microsoft.SharePoint.PostSetupConfiguration.UpgradeTask.Run() at Microsoft.SharePoint.PostSetupConfiguration.TaskThread.ExecuteTask() at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext....
03/14/2013 21:36:45.49* psconfig.exe (0x04B8) 0x0C88 SharePoint Foundation Topology 8xqz Medium ...Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Threading.ThreadHelper.ThreadStart()

03/14/2013 21:36:45.88 psconfig.exe (0x04B8) 0x0C88 SharePoint Foundation Upgrade g4z9 Medium Stop SessionMaintenanceThread by signaling s_EventStopThread

I have a sneaking suspicion this has nothing to do with Managed Meta Data - my next attempt will not have that service provisioned.

csyvenky wrote Mar 15, 2013 at 5:36 PM

Wow I guess trying to add ASCII formatting in the comments field is a really bad thing; sorry that was suppose to be a series of paragraphs separated by dashes and equals signs.

wrote Mar 16, 2013 at 10:25 AM

brianlala wrote Mar 18, 2013 at 3:00 AM

More info. I managed to repro the issue a few days ago. However I remembered to launch ULSViewer while the script was running. The last entry in the ULS logs for powershell.exe process is this:

Blocking until timer job '65a7cd06-b598-4ede-92b3-9ec1417cf695' has completed.

Then I went looking for this timer job soon afterwards (w/ Get-SPTimerJob) but couldn't find it.

I actually left/forgot the script in that 'hung' state after "Creating Metadata Service Application...", and interestingly, after an undetermined period of time, it finally errored out with:

New-SPMetadataServiceApplication : The timer job did not complete running within the allotted time.
At \brilalawin8\SP\AutoSPInstaller\AutoSPInstallerFunctions.ps1:1768 char:39
  • $metaDataServiceApp = New-SPMetadataServiceApplication -Name $me ...
  • ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    • CategoryInfo : InvalidData: (Microsoft.Share...MetadataService:SPCmdletNewMetadataService) [New-SPMetad
      ataServiceApplication], TimeoutException
    • FullyQualifiedErrorId : Microsoft.SharePoint.Taxonomy.Cmdlet.SPCmdletNewMetadataService
I'm inclined to think that this is a bug in the provisioning process rather than AutoSPInstaller (naturally :)) but it requires more digging.


csyvenky wrote Mar 19, 2013 at 7:48 PM

I am literally receiving this 100% of the time. I have had three attempts in a multi-tier environment fail.

My Managed Metadata Service Application configuration is like this:
<ManagedMetadataServiceApp Provision="123SomeServerName456"
                                   Name="Managed Metadata Service"
                                   ProxyName="Managed Metadata Service Proxy">
            <!-- You can specify a different DB server/instance or alias per web application and service application. The behavior is slightly different than with the farm DB server though, see below. -->
                <!-- <Name> designates the suffix portion of the database name. For example if your DBPrefix (above) was "SPFarm", and the name below was "ServiceApp", your full DB name would be "SharePoint_ServiceApp" -->
                <!-- If you are creating an alias (recommended!), <DBServer> is actually the value of the SQL alias; otherwise it's the NetBIOS name of the SQL server or instance. 
                     If you leave <DBServer> blank, the default DBServer value for the farm is used -->
                <!-- The script can create a SQL alias for you. Enter the DBInstance, and if you leave <DBPort> blank, script will assume default port value of 1433 -->
                <DBAlias Create="false"
                         DBPort="" />
If I re-attempt with provisioning set to false - the install fails trying to provision the User Profile Service application, claiming that one already exists.
New-SPProfileServiceApplication : The name you specified is already being used
by another Profile Service Application. Please provide another name.
At C:\Users\coryadmin\AppData\Local\Temp\1\AutoSPInstaller-ScriptBlock.ps1:3

csyvenky wrote Mar 20, 2013 at 12:00 AM

I tried the 3.85 release and these problems go away - mind you a key difference is I am basically leaving the defaults for Service Applications with this release, whereas with 3.2 I was trying to control and scale back on the service applications.

wrote Jul 29, 2013 at 1:27 PM

wrote Sep 19, 2013 at 7:03 PM

deafknight wrote Sep 19, 2013 at 7:04 PM

This still happens with 3.95
The timer Job for provisioning the SA never finishes or never signals it has finished, or something :)
I have to reboot, then launch again, and it completes to the end.

deafknight wrote Sep 23, 2013 at 2:25 PM

This is persistent, under windows server 2012 at least.
If i delete the MMS and start the script again, it gets stuck each time provisioning the MMSA.
I noticed the second time, the MMSA gets created, but in the "stopped" state.

alexbacchin wrote May 6, 2014 at 4:02 AM

Need to reset the SPTimer Job to get this working

$configdb=Get-SPDatabase | where Type -eq "Configuration Database"
$configdbId = $configdb.Id
Stop-Service -Name SPAdminV4
$sptimercache = "C:\ProgramData\Microsoft\SharePoint\Config\$configdbId"
Remove-Item $sptimercache*.xml
1 | Out-File $sptimercache\cache.ini
Start-Sleep 4
Start-Service -Name SPAdminV4

wrote Nov 27, 2017 at 6:36 PM