Deploying dacpac through Powershell caused an error: "Unable to determine domain identity"

Question

Has anyone else encountered a similar problem with the one described below?

I had a problem deploying a dacpac database update for SQL Server 2012 using Powershell. Details are as follows:

Its a dacpac file created for SQL Server 2012, and I'm trying to apply it to the sql server 2012 database through Powershell, which is run from the command line when logged in as an administrator.

The deployment exception is thrown with argument "4": "Unable to determine the identity of the domain." In ... so.ps1: 17 char: 8 + $ d.Deploy ($ dp, $ TargetDatabase, $ true, $ DeployOptions)

The modified script (log and literals changed) is as follows:

[System.Reflection.Assembly]::LoadFrom("C:\Program Files (x86)\Microsoft SQL Server\110\DAC\bin\Microsoft.SqlServer.Dac.dll") | Out-Null $d = new-object Microsoft.SqlServer.Dac.DacServices ("... Connection string ...") $TargetDatabase = "databasename" $fullDacPacPath = "c:\temp\...\databasename.dacpac" # Load dacpac from file & deploy to database named pubsnew $dp = [Microsoft.SqlServer.Dac.DacPackage]::Load($fullDacPacPath) $DeployOptions = new-object Microsoft.SqlServer.Dac.DacDeployOptions $DeployOptions.IncludeCompositeObjects = $true $DeployOptions.IgnoreFileSize = $false $DeployOptions.IgnoreFilegroupPlacement = $false $DeployOptions.IgnoreFileAndLogFilePath = $false $DeployOptions.AllowIncompatiblePlatform = $true $d.Deploy($dp, $TargetDatabase,$true,$DeployOptions) 

Here is some supporting information:

• Dac Frame Version - 11.1
• The script throws an error at startup on the command line:
  i.e. Powershell -File databaseupgrade.ps1
  but not when run in Powershell script integrated environment
• Similar scripts work from the command line for other dacpacs.

Internet research may seem that this may be due to the size of dacpac. Those that work are smaller than the one that doesn't work, and this link mentions a 1.3 MB digit whose file size does not match the duppack. If anyone can confirm that this is a problem, can you also offer a solution?

Update The following scripts demonstrate the same behavior, that is. works in PS. Idea is not from the command line.

 [Reflection.Assembly]::LoadWithPartialName("System.IO.IsolatedStorage") $f = [System.IO.IsolatedStorage.IsolatedStorageFile]::GetMachineStoreForDomain(); Write-Host($f.AvailableFreeSpace); 

Answer 1

I believe that this problem here (at least in our case) is actually when dacpac is working with a database that uses multiple filegroups. When comparing for deployment, my hypothesis is that it uses IsolStorage for different files.

The link above was useful, but it was not the same entry as the last comment on this blog by Tim Lewis . I changed his code to work in native powershell. If you install this above the SMO build download, fix this problem:

$replacementEvidence = New-Object System.Security.Policy.Evidence $replacementEvidence.AddHost((New-Object System.Security.Policy.Zone ([Security.SecurityZone]::MyComputer))) $currentAppDomain = [System.Threading.Thread]::GetDomain() $securityIdentityField = $currentAppDomain.GetType().GetField("_SecurityIdentity", ([System.Reflection.BindingFlags]::Instance -bOr [System.Reflection.BindingFlags]::NonPublic)) $securityIdentityField.SetValue($currentAppDomain,$replacementEvidence)

Answer 2

Edit - this answer is incorrect, see the link added to the original question for information on the real root cause.

It looks like you are trying to connect to Windows Authentication and that is the reason for the failure (see this post , as it seems to cover the error message you are getting). Change the connection string to use SQL authentication or make sure that the user is working with your powershell script program, as both have an identifier attached to the domain and have permissions to access the server. Basically, this is a problem with the SQL connection, not a DAC problem.

Answer 3

It has been several days, so I do not think that an appropriate explanation will appear. I will simply post this as our way of circumventing anyone who finds themselves in this situation. There is a Microsoft SqlPackage.exe command-line tool that is pretty easy to get. It will silently deploy dacpac, can be executed in Powershell and has parameters that support all the parameters we need. If we use this instead of building Dac services directly, the domain problem does not occur.