none
Не выполняется файл, запускаемый скриптом vbs, заданным в GPO как startup script RRS feed

  • Общие обсуждения

  • Продолжение темы http://social.technet.microsoft.com/Forums/ru-RU/windowsserverru/thread/6f7dcd4e-914e-4906-b246-fb2097abf56f

    Собстевнно сабж.

    Файл запускается что WshShell.Run, что WshShell.Exec - ни тот, ни другой метод не приводит к успеху. (запускаемый файл dotNetFx40_Full_x86_x64.exe /q). Ошибки нет, установки dotNet тоже нет. Захожу под админом, запускаю руками - всё работает. Пишу батник с командой dotNetFx40_Full_x86_x64.exe /q, ставлю его в GPO вместо vbs - тоже всё работает.

    Что за мистика, знает кто?

    • Изменен тип Vinokurov YuriyModerator 14 января 2011 г. 7:48 давность и отсутствие активности в теме
    26 декабря 2010 г. 14:51

Все ответы

  • Если речь идет именно об установке 4-го фреймворка, то зачем же так лезть на амбразуру? Во-первых, есть WSUS, который спокойно может распространить это обновление. Во-вторых, кое-где есть Configuration Manager, тоже справится. Ну и наконец, в-третьих, есть установка msi-пакетов через ту же групповую политику. А если речь идет только о проверках перед установкой, то инструментарий WMI-фильтров прикрученных к GPO с установкой msi-пакета и вперед!

    Или Вы за идею?


    Решаю проблемы...
    26 декабря 2010 г. 18:21
  • Да, о WSUS слышал. Но мне это представляется сродни палить пушкой по воробьям. Да и хочется придерживаться какой-то последовательности: от простого к сложному. Вот нужно мне всего-то навсего раздать .NET Framework 4, MSI -пакета которого на сегодняшний день - нет (или я ошибаюсь?). Ну и в конце концов, хочу сначала понять причину, почему ТАК не работает.

    Вот снова грабли с запуском .exe (наверняка не случайно - видимо что-то я не знаю, что мне следовало бы знать): раздаю свой exe-шник уже не vbs, а bat-скриптом - всё работает. НО! Когда пользователь включает комп, он видит долговисящую "применение политик" и ждёт, пока этот фрэймворк установиться. Это не приемлемо. Поэтому я делаю следующее: в строке запуска exe-шника ставлю команду start installDotNet.exe. В расчёте на то, что установщик запустится в фоновом режиме и пользователю не придётся ждать окончания установки. И что же я получаю: установка теперь нихрена не происходит (ни ошибки, ни следа запуска опять!). Захожу в комп, нахожу свой bat-скрипт, запускаю - всё работает.

    Что за магия, обьяснит кто???

    P.S.: А если мне нужно будет какие-нибуть "третьи" программы ставить для которых MSI нет в природе, что тогда делать?

    27 декабря 2010 г. 12:38
  • Вы знаете, года три назад я тоже считал, что обязательно необходим универсальный метод автоматической установки приложений. В своих разработках я дошел до AutoIt, скриптового языка программирования, который позволял на самый крайний случай имитировать действия пользователя в программе установки вплоть до нажатия необходимых кнопок или движений мыши. Однако позже выяснилось, что большинство программ имеют как минимум ключи тихой установки, а как максимум msi-пакет установщика. Оказалось, что универсальность вовсе не требуется, а требуется грамотное использование технологий, которые сама же Майкрософт рекомендует использовать для своих продуктов (в данном случае речь идет об ОС семейства Windows).

    Таким образом, во-первых, как Вы собираетесь обеспечивать надлежащий уровень безопасности в Вашей сети, если не планируете применять WSUS, который в том числе служит для распространения заплаток, коих, поверьте, в тех же Framework'ах вагон и маленькая тележка? Предлагаете, чтобы следующим шагом было скачивание всех апдейтов для Framework и вопросы типа "Почему не устанавливается msi пакет скриптом vbs"? Во-вторых, все установочные пакеты от Майкрософт так или иначе основаны на Windows Installer, а значит у них есть msi, которые, бывает, запакованы внутри exe-макрофайла. И в-третьих существует программное обеспечение, типа softgrid или просто всевозможные msi-конструкторы, которые позволят Вам из любого exe-файла так или иначе сделать msi.


    Решаю проблемы...
    27 декабря 2010 г. 14:20
  • Спасибо за информативный ответ.

    Внутри exe-файла 4-го фреймворка действительно есть mis-пакеты, но они не хотят распространяться: To install this product please run Setup.exe. Для 3-го судя по информации из интернета - есть нормальный msi-пакеты. Почему мне нужен именно 4-й? Потому что я на свою голову написал и скомпилил exe-файл, который должен работать на каждом компьютере, при чём писал на скачанном из microsoft.com Visual Basic Express. А созданный таким образом exe-файл требует установленной .Net Framework 4. Вот и пошло, поехало.

    Короче, "якось будэ". Видимо придётся потерпеть моим пользователям при запуске политики после включения компа.

    WSUS пока разбирать нет времени.

    27 декабря 2010 г. 18:41
  • Я на прошлой неделе решал такую же проблему, только с версией 3.5. Решение в обход WSUS есть и я его попробовал. Не знаю насколько разное содержание дистрибутива в сравнении с версией 4, но некоторые Ваши проблемы, я думаю описанный тут способ решит http://social.technet.microsoft.com/Forums/ru-RU/windowsserverru/thread/97ea15f3-91e9-47cb-b005-e099349c6967.

    27 декабря 2010 г. 18:52
  • Кстати, забыл отметить, что на данный момент вообще не заморачиваюсь на установку различных программных продуктов, а использую RemoteApp. При чем здесь это, спросите Вы? Именно при том. При том, что по-моему мнению это и есть определенная вершина в развертывании ПО. Вы не представляете себе, какой кайф я лично испытываю, когда после сноса ОС все необходимые приложения у меня появляются, не успею я моргнуть глазом. Какой кайф от того, что тот же Microsoft Office устанавливается примерно за 20 секунд и не нужно заморачиваться, что на клиенте не установлены необходимые фреймворки и прочая саттелитная ерундистика.

    Кстати опыт разработки собственных приложений и распространения их через RemoteApp у нас тоже проходит на ура. При этом никаких инсталляторов собирать не нужно, достаточно лишь добиться чтобы приложение работало на терминальном сервере и распространить msi-пакет RemoteApp. Расширяйте границы познания, удачи! :)


    Решаю проблемы...
    28 декабря 2010 г. 18:21
  • >Вы не представляете себе, какой кайф я лично испытываю, когда после сноса ОС все необходимые приложения у меня появляются, не успею я моргнуть глазом

    Вы не забыли рассказать о том, во сколько обойдется этот кайф?

    По subj'у: касательно развертывания dotNet. Не мучайте себя, разверните WSUS. Это очень простая, полезная во всех отношениях пушка и, ко всему прочему, совершенно бесплатная.

    >А если мне нужно будет какие-нибуть "третьи" программы ставить для которых MSI нет в природе, что тогда делать?

    самостоятельно изготовить для таких программ msi. Для изготовления msi существует большое количество ПО, как платного, так и бесплатного (например, погуглите в сторону  wininstall le)


    blog: http://shss.wordpress.com/
    2 января 2011 г. 17:44
  • Решается элементарно небольшой правкой msi файлов с помощью Orca (MSI SDK). Могу дать доступ уже к подготовленной административной точке. Если надо - сообщите здесь, дам ссылку. Может - и статью напишу :-)


    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    14 января 2011 г. 9:51
  • Э, неее, не учите плохому. Лучше WiX+Visual Studio ничего нет. С помощью wininstall le только информацию можно собрать, использовать то, что он наделает - не рекомендую. То, что он сделает - разбираем, включаем мозги, MSDN, MSI SDK, VS+WiX - и получаем действительно нормальный дистрибутив. Например - для 1С: http://sergey-s-betke.blogs.novgaro.ru/1cmsi-2 :-)


    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    14 января 2011 г. 10:01
  • Отвечая на исходный "неправильный" вопрос: а можно глянуть на строки, которые Вы отдаёте WshShell.Run? Надо бы предварительно диск сетевой подцепить и с него уже и пускать то, что Вам надо. Или вы UNC путь отдаёте? а Ваш компьютер (типа Workstation$) имеет доступ к ресурсу с к дистрибутивом?


    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    14 января 2011 г. 10:04
  • Месяц назад решал аналогичную задачу с .NET 3.5 SP1. В конце концов пришёл к выводу, что Deployment Guide всё описывает абсолютно точно, нужно просто внимательно его читать. Для 4-го фреймворка есть свой Deployment Guide.
    17 января 2011 г. 14:16
  • Вроде подходящая тема. Как указать в теле vbs скрипта запуск msi пакета с параметрами? Например, у меня есть строчка

    installOrUninstall InstallUID, DistrFolder + "8.2.13.219\1CEnterprise 8.2.msi", "1049.mst", "adminstallrestart.mst", requiredInstall

    Мне нужна тихая установка данного пакета при старте компа. Если прописать так - 1CEnterprise 8.2.msi /qn, то скрипт не отрабатывает.

    21 апреля 2011 г. 14:21
  • Вот пример с сайта http://www.itland.ru/forum/index.php?showtopic=19121:

    ---Cut---

    Dim WshShell, oExec

    Set WshShell = CreateObject("WScript.Shell")

    Set oExec = WshShell.Exec("msiexec /i ""\\server\install\1cv81\R8.1.6.38\1CEnterprise 8.1.msi"" TRANSFORMS=\\server\install\1cv81\R8.1.6.38\setup.MST /qb")

    Do While oExec.Status = 0
    WScript.Sleep 100
    Loop

    WScript.Echo "Установка завершена"

    ---Cut---

    Если у вас по каким-то причинам не отрабатывает ключ "/qn", используйте "/qb-".


    21 апреля 2011 г. 15:42
  • Ну зачем же так то? msi имеет одну из множества положительных сторон: публикация сценария установки непосредственно в GPO. Там в разделе "политика ПК" есть раздел "Установка программного обеспечения". Готовьте предварительно административную точку установки и выкладывайте в GPO. никаких vb сценариев не надо, и при каждой загрузке никаких проблем не будет возникать. Один раз встало - и всё.

    Зачем же с MSI пакетом такие чудеса выдумывать? Удобно создавать административную точку можно так http://sergey-s-betke.blogs.novgaro.ru/inf-for-msiexec. А пример публикации msi пакета в политику здесь: http://sergey-s-betke.blogs.novgaro.ru/ustanovka-d-link-d-viewcam.


    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    22 апреля 2011 г. 4:21
  • Ну зачем же так то? msi имеет одну из множества положительных сторон: публикация сценария установки непосредственно в GPO. Там в разделе "политика ПК" есть раздел "Установка программного обеспечения". Готовьте предварительно административную точку установки и выкладывайте в GPO. никаких vb сценариев не надо, и при каждой загрузке никаких проблем не будет возникать. Один раз встало - и всё.

    Зачем же с MSI пакетом такие чудеса выдумывать? Удобно создавать административную точку можно так http://sergey-s-betke.blogs.novgaro.ru/inf-for-msiexec. А пример публикации msi пакета в политику здесь: http://sergey-s-betke.blogs.novgaro.ru/ustanovka-d-link-d-viewcam.


    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru

    Да не от хорошей жизни скрипт. К сожалению, 1С 8.2 не будет обновляться нормально через публикацию msi пакетов. В 8.2 каждый последующий установленный релиз не обновляет предыдущий, а ставится рядом. А мне надо, чтоб предыдущий удалялся и ставился свежий.

    Всем спасибо, вопрос снят.


    22 апреля 2011 г. 6:08
  • А кто же мешает при публикации в GPO указывать пакет, который будет обновлён новым пакетом? и Вы можете сами указать - обновлять или заменять. При замене предыдущий будет снесён перед установкой нового. И никаких скриптов...


    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    22 апреля 2011 г. 7:19
  • Есть такая магия с неработающей командой start в bat-файле, запускаемом как startup-скрипт. Причины мне не известны, как раз гуглю про них настоящий момент. Обходное решение - положить в одну папку с экзешником psexec.exe и назначить startup-скриптом bat-файл (для вашего случая):

    set DIR0=%~p0
    set DIR0=%~d0%DIR0:~0,-1%

    "%DIR0%\psexec.exe" -accepteula -d -s cmd.exe /C dotNetFx40_Full_x86_x64.exe /q

    Выполняется в фоне, не задерживает пользователя со входом в систему.


    28 июня 2011 г. 10:01