Skip to content

October 18, 2016


ADFS: Raise Farm Behavior Level Issue

After upgrading our ADFS servers to Windows Server 2016, the last step was to raise the Farm Behavior Level using the Invoke-AdfsFarmBehaviorLevelRaise PowerShell cmdlet. In my case, when I ran this command, I received the following error:

Invoke-AdfsFarmBehaviorLevelRaise : Database upgrade could not be performed on localhost. Error: Unable to connect to
the database. You may not have permission to create the AD FS configuration database in the specified SQL server. You
can do one of the following: (1) have the SQL administrator grant permissions to you to create the AD FS configuration
database in the specified SQL server or (2) have the SQL administrator create the AD FS configuration database by
running  SQL scripts. Use the Export-ADFSDeploymentSQLScript to create the SQL scripts. After the SQL administrator
runs the scripts, try the command again specifying that the database is to be overwritten.
At line:1 char:1
+ Invoke-AdfsFarmBehaviorLevelRaise
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [Invoke-AdfsFarmBehaviorLevelRaise], RemoteException
+ FullyQualifiedErrorId : DeploymentTask,Microsoft.IdentityServer.Deployment.Commands.InvokeUpgradeFarmBehaviorCom

Unable to create a newer version of the configuration database. Database upgrade could not be performed on localhost…
In my case, I have a few advanced configurations that may have triggered this error.  First, my ADFS databases are hosted on a remote SQL Server with HA redundancy using SQL AlwaysOn. Also, my ADFS service runs with a gMSA account (Global Managed Service Account).
As of the time of this article, there is my limited documentation on the Invoke-AdfsFarmBehaviorLevelRaise cmdlet. I discovered I could solve this issue by specifying Admin credentials using the -Credential parameter and specifying the -GroupServiceAccountIdentifier parameter to be my gMSA as optional parameters to the Invoke-AdfsFarmBehaviorLevelRaise cmdlet.
In the end, my cmdlet looked like this:
$cred = Get-Credential
Invoke-AdfsFarmBehaviorLevelRaise -Credential $cred -GroupServiceAccountIdentifier <DOMAIN>\mygMSA$
If you are running a similar ADFS configuration and run into this issue, trying adding some the optional parameters to solve the issue.
7 Comments Post a comment
  1. GJ
    Oct 27 2016

    I have also had similar issue, however I omitted gMSA details on my cmdlet.

    at the end my cmdlet looked like this: $cred = Get-Credential
    Invoke-AdfsFarmBehaviorLevelRaise -Credential $cred

  2. David Vanderslice
    Oct 28 2016

    I also have a SQL Always On cluster that hosts our ADFS database and am eager to upgrade. I was afraid this issue would arise. After you defined the credential as the gMSA you were good to go?

    I actually contacted the tech writers at Microsoft if they would be releasing the documentation for the SQL hosted ADFS database and they said a couple weeks.

    You are a true champion for posting this!

    • Brent
      Oct 28 2016

      I actually used Domain Admin credential for -Credential to be able to make changes on the SQL database, but then specified gMSA details (not sure if that is required as well or not). Glad MS will be updating their docs.

  3. Horgster
    Nov 3 2016

    Hi Guys,

    Faced the same issue, but resolved the issue by using Domain Admin account.

    $cred = Get-Credential
    Invoke-AdfsFarmBehaviorLevelRaise -Credential $cred

    But, if you are using SQL AlwaysOn, please notice that this cmd-let created an new ADFS Configuration Database, named “AdfsConfigurationV3”

    Remember to add this DB as part of your Always On Group in SQL

    • Brent
      Nov 3 2016

      Yeah that’s a good point that I should have mentioned…when using AAG don’t forgot to add the new DB it creates to AAG. thanks for mentioning that.

    • David Vanderslice
      Nov 27 2016

      Performed our upgrade with the similar SQL Always On cluster. Ran the cmdlet specifying the GMSA. No problem, though i had to modify the master DB to grant permission to the domain admin specified in $cred to CREATE DATABASE.
      After it changed the trusts with:
      SSO lifetime was increased from 60480min to 129600min
      Device usage window was upgraded from 7 days to 14 days

      Also if your PDC Emulator is not running Windows 2016, even after you prepped the forest and domain you’ll need to move the PDC FSMO role to it so that it’ll auto create the Enterprise Key Admins group. That way you can add your GMSA there manually. Our PDC was running 2012 R2 so it even tells you that you need to add that service account to that group.

      Otherwise, thanks again.

      • David Vanderslice
        Nov 28 2016

        One other thing i ran into, i had to detach the old ADFSCONFIGURATION database as when you join a new ADFS server to the farm and you have both the V3 and the original config databases you need to manually point it to the new DB. Easiest way was detach that DB.


Leave a Reply to David Vanderslice


Note: HTML is allowed. Your email address will never be published.

Subscribe to comments