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
mand
Message
——-
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 \mygMSA$
If you are running a similar ADFS configuration and run into this issue, trying adding some the optional parameters to solve the issue.