Я нашел следующий пост - https://blogs.msdn.microsoft.com/troy_aults_blog/2017/01/13/automating-installation-of-ssms-with-dsc/
Отлично, теперь все, что мне нужно знать, это идентификатор продукта SSMS-Setup-ENU.exe, верно?
Но как, черт возьми, я должен это делать? Когда я установил его на другой компьютер и попробовал подход, описанный в https://blogs.msdn.microsoft.com/brian_farnhill/2017/07/04/getting-ids-to-use-with-the-package-dsc-resource/ У меня два идентификатора продукта:
PS C:\> $x86Path = "HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*"
PS C:\> $installedItemsX86 = Get-ItemProperty -Path $x86Path | Select-Object -Property DisplayName, PSChildName
PS C:\> $x64Path = "HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*"
PS C:\> $installedItemsX64 = Get-ItemProperty -Path $x64Path | Select-Object -Property DisplayName, PSChildName
PS C:\> $installedItems = $installedItemsX86 + $installedItemsX64
PS C:\> $installedItems | Where-Object -FilterScript { $null -ne $_.DisplayName } | Sort-Object -Property DisplayName | sls 'Management Studio'
@{DisplayName=Microsoft SQL Server Management Studio - 17.4; PSChildName={ac84c935-8f13-4f73-b541-7b09a11bdea8}}
@{DisplayName=SQL Server 2017 Management Studio Extensions; PSChildName={6492E746-1C5D-48C2-A92A-97D431F74664}}
@{DisplayName=SQL Server 2017 Management Studio Extensions; PSChildName={70C24F35-7E36-45FC-B289-3D2849E5556B}}
@{DisplayName=SQL Server Management Studio; PSChildName={F8ADD24D-F2F2-465C-A675-F12FDB70DB82}}
@{DisplayName=SQL Server Management Studio; PSChildName={1B8CFC46-1F08-4DA7-9FEA-E1F523FBD67F}}
@{DisplayName=SQL Server Management Studio for Analysis Services; PSChildName={CC6997A7-1638-4E38-B6CF-E776997036B0}}
@{DisplayName=SQL Server Management Studio for Reporting Services; PSChildName={4DDEB555-26D2-4E68-98AF-8F96232C13F2}}
На самом деле я пробовал другой подход, который дает тот же результат (вероятно, потому, что оба «сидят» на одних и тех же данных):
PS C:\> get-wmiobject Win32_Product -Filter "Name like '%sql%management%studio%'" | sort -Property Name | Format-Table IdentifyingNumber, Name, LocalPackage -AutoSize
IdentifyingNumber Name LocalPackage
----------------- ---- ------------
{6492E746-1C5D-48C2-A92A-97D431F74664} SQL Server 2017 Management Studio Extensions C:\Windows\Installer\43f1a.msi
{70C24F35-7E36-45FC-B289-3D2849E5556B} SQL Server 2017 Management Studio Extensions C:\Windows\Installer\43f16.msi
{F8ADD24D-F2F2-465C-A675-F12FDB70DB82} SQL Server Management Studio C:\Windows\Installer\43f23.msi
{1B8CFC46-1F08-4DA7-9FEA-E1F523FBD67F} SQL Server Management Studio C:\Windows\Installer\43f27.msi
{CC6997A7-1638-4E38-B6CF-E776997036B0} SQL Server Management Studio for Analysis Services C:\Windows\Installer\43f43.msi
{4DDEB555-26D2-4E68-98AF-8F96232C13F2} SQL Server Management Studio for Reporting Services C:\Windows\Installer\43f3c.msi
Оба метода дают два идентификатора продукта:
Итак, какой из них правильный? Есть ли более детерминированный способ справиться с безумием определения правильного идентификатора продукта?
Я думаю, что наконец понял, что происходит, хотя мне еще предстоит проверить, поможет ли это мне установить SSMS с помощью Azure Automation DSC.
Вот что я сделал:
<BurnManifest xmlns="http://schemas.microsoft.com/wix/2008/Burn"> из чего я сделал вывод, что exe был создан с помощью WIX burn.dark.exe -x d:\temp SSMS-Setup-ENU.exe, который извлек много файлов msi из SSMS-Setup-ENU.exe в d:\temp.Сценарий PowerShell:
param(
[Parameter(Mandatory = $true, Position = 0, ValueFromPipeline = $true)]
[ValidateScript({ ($_ -match "\.msi$") -and (Test-Path $_ -PathType Leaf)})]
$path)
process
{
$comObjWI = New-Object -ComObject WindowsInstaller.Installer
$MSIDatabase = $comObjWI.GetType().InvokeMember("OpenDatabase","InvokeMethod",$Null,$comObjWI,@("$Path",0))
$props = @{ Path = "$path" }
@('ProductCode', 'ProductName') |% {
$Query = "SELECT Value FROM Property WHERE Property = '$_'"
$View = $MSIDatabase.GetType().InvokeMember("OpenView","InvokeMethod",$null,$MSIDatabase,($Query))
$View.GetType().InvokeMember("Execute", "InvokeMethod", $null, $View, $null)
$Record = $View.GetType().InvokeMember("Fetch","InvokeMethod",$null,$View,$null)
$props[$_] = $Record.GetType().InvokeMember("StringData","GetProperty",$null,$Record,1)
}
New-Object psobject -Property $props
}
Последняя командная строка:
PS C:\> $g1 = "1B8CFC46-1F08-4DA7-9FEA-E1F523FBD67F"
PS C:\> $g2 = "F8ADD24D-F2F2-465C-A675-F12FDB70DB82"
PS C:\> dir D:\temp\AttachedContainer\x64\*.msi | .\GetProductCodeFromMSI.ps1 | sls "($g1|$g2)"
@{Path=d:\temp\AttachedContainer\x64\sql_ssms.msi; ProductName=SQL Server Management Studio;
ProductCode={F8ADD24D-F2F2-465C-A675-F12FDB70DB82}}
@{Path=d:\temp\AttachedContainer\x64\sql_ssms_loc.msi; ProductName=SQL Server Management Studio;
ProductCode={1B8CFC46-1F08-4DA7-9FEA-E1F523FBD67F}}
PS C:\>
Таким образом, оба кода продукта находятся в одной установке SSMS и соответствуют sql_ssms.msi и sql_ssms_loc.msi. У обоих одинаковое название продукта - SQL Server Management Studio.
Теперь я понятия не имею, что такое sql_ssms_loc.msi, но я собираюсь попробовать использовать F8ADD24D-F2F2-465C-A675-F12FDB70DB82, потому что он соответствует sql_ssms.msi. Вернусь с результатами.
ИЗМЕНИТЬ 1
Использование F8ADD24D-F2F2-465C-A675-F12FDB70DB82, похоже, сработало.