Я создаю «золотой образ» Windows, который будет развернут в сети, не имеющей прямого доступа в Интернет. Вместо этого трафик HTTP / HTTPS должен передаваться через прокси-сервер.
При беге sysprep, Я добавляю это в unattend.xml, чтобы автоматически настроить параметры прокси в золотом образе:
<component name="Microsoft-Windows-IE-ClientNetworkProtocolImplementation" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State">
<POLICYProxySettingsPerUser>0</POLICYProxySettingsPerUser>
<HKLMProxyEnable>true</HKLMProxyEnable>
<HKLMProxyServer>outboundproxy.example.com:3128</HKLMProxyServer>
</component>
(Это взято из сообщения на https://blogs.technet.microsoft.com/chrad/2009/07/13/dynamic-provisioning-with-vmm-proxy-windows-updates-and-scripts/)
После запуска sysprep, создав образ, а затем развернув виртуальную машину из образа, я смог войти на рабочий стол, перейти в «Настройки» -> «Настройки прокси» и убедиться, что прокси настроен правильно. IE и другие приложения работали как положено.
Однако позже я обнаружил, что программные процессы, запускаемые при запуске, не использовали настройки прокси-сервера и поэтому не работали. После некоторых экспериментов я обнаружил, что настройки прокси не вступали в силу, пока пользователь не вошел в сеанс рабочего стола. После того, как пользователь вошел в систему, те же процессы, которые не работали до этого, начали успешно использовать HTTP-прокси. Поэтому кажется, что sysprep не настраивал прокси - вместо этого какой-то пользовательский процесс, вызванный при ведении журнала, отвечал за завершение конфигурации.
Поскольку это среда, которая в значительной степени полагается на автоматизацию, и поскольку это серверы, а не рабочие столы пользователей, важно, чтобы они работали правильно без входа пользователя в систему.
Есть ли способ настроить параметры HTTP-прокси в sysprep золотой образ, который не зависит от входа пользователя на рабочий стол?
В этой конфигурации мы используем Windows Server 2019, но я полагаю, что эта проблема характерна для многих версий Windows.