【问题标题】:Deploying a dacpac via Powershell caused error: "Unable to determine the identity of domain"通过 Powershell 部署 dacpac 导致错误:“无法确定域的身份”
【发布时间】:2014-01-28 02:10:42
【问题描述】:

有没有其他人遇到过与下面描述的类似的问题?

我在使用 Powershell 部署 SQL Server 2012 dacpac 数据库升级时遇到问题。详情如下:

它是为 sql server 2012 构建的 dacpac 文件,我正在尝试通过 Powershell 在以管理员身份登录时从命令行运行将其应用于 sql server 2012 数据库。

使用“4”个参数调用“Deploy”的异常:“无法确定域的身份。” 在 ... so.ps1:17 char:8 + $d.Deploy($dp, $TargetDatabase,$true,$DeployOptions)

编辑后的脚本(日志和文字已更改)如下:

   [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) 

以下是一些支持信息:

  1. Dac 框架版本为 11.1
  2. 脚本在命令行运行时抛出错误:
    IE。 Powershell -File databaseupgrade.ps1
    但不是在 Powershell 集成脚本环境中运行时
  3. 其他 dacpac 的命令行也可以使用类似的脚本。

网络研究可能表明这可能与 dacpac 的大小有关。工作的都比不工作的小,this link 提到失败的 dacpac 的文件大小刚好超过 1.3mb 的数字。如果有人可以确认这是问题所在,您能否提出解决方案?

更新 以下脚本表现出相同的行为,即。在 PS Ide 中工作而不是从命令行。

[Reflection.Assembly]::LoadWithPartialName("System.IO.IsolatedStorage")

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

【问题讨论】:

    标签: sql-server powershell dacpac


    【解决方案1】:

    编辑 - 此答案不正确,有关真正根本原因的信息,请参阅原始问题中添加的链接。

    听起来您正在尝试使用 Windows 身份验证进行连接,这就是失败的原因(请参阅this post,因为它似乎涵盖了您收到的错误消息)。更改您的连接字符串以使用 SQL 身份验证或确保您的 powershell 脚本正在运行的用户具有加入域的身份并有权访问服务器。基本上,这是 SQL 连接问题而不是 DAC 问题。

    【讨论】:

    • 我猜我从脚本中删除了太多信息。使用的连接字符串类似于:“data source=servername;initial catalog=dbname;user id=deploy;password=p455w0rd;”如果我理解它,那就排除了上面的建议。关于更多信息。我正在使用计算机上的管理员帐户通过远程桌面连接连接到服务器。
    • 啊,谢谢你的澄清。 Dacpacs 使用您链接到的那篇文章中提到的 OpenXML 和 System.IO.Packaging API,所以也许按照那里提到的步骤(为此代码使用单独的 AppDomain)可能有效?我不认为有一个特定的配置选项可以传递给 DacServices 代码来避免这个问题 - 这是它的依赖关系的问题。
    【解决方案2】:

    现在已经有几天了,所以我认为不会有适当的解释。我将把它作为我们的解决方法发布给任何发现自己处于这种情况的人。 有一个相当容易掌握的 Microsoft 命令行程序 SqlPackage.exe。它将静默部署 dacpac,可以在 Powershell 中执行,并且具有支持我们需要的所有选项的参数。 如果我们直接使用它而不是 Dac 服务程序集,则不会出现域问题。

    【讨论】:

      【解决方案3】:

      我相信这里的这个问题(至少在我们的例子中)实际上是当 dacpac 正在使用一个使用多个文件组的数据库时。在进行部署比较时,我的假设是它为不同的文件使用了 IsolatedStorage。

      link above 很有帮助,但它不像 Tim Lewis 在该博客上的最后一条评论那么重要。我修改了他的代码以在本机 powershell 中工作。将其置于 SMO 程序集负载之上应该可以解决此问题:

      $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)

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2021-01-25
        • 2016-10-05
        • 2012-05-19
        • 2022-08-09
        • 2013-01-15
        • 1970-01-01
        • 1970-01-01
        • 2018-11-02
        相关资源
        最近更新 更多