Mass installation?
December 9, 2008 8:59 AM Subscribe
What's the best way to mass install over an Active Directory network?
Currently I'm running an network of around 60 computers, most of these are XP although there's some Windows 2003 and 2007 also.
The problem is all these computers remain logged in 24/7 and are locked when not in use, never logged out. I'm a novice Windows network admin and any ideas on how to push software to these computers?
I understand that you can set group policies to run .msi installers, however these are only run upon login and due to these computers rarley actually logging in...as they don't logout this isn't much use.
Any suggestions would be extremely appreciated. Thanks.
Currently I'm running an network of around 60 computers, most of these are XP although there's some Windows 2003 and 2007 also.
The problem is all these computers remain logged in 24/7 and are locked when not in use, never logged out. I'm a novice Windows network admin and any ideas on how to push software to these computers?
I understand that you can set group policies to run .msi installers, however these are only run upon login and due to these computers rarley actually logging in...as they don't logout this isn't much use.
Any suggestions would be extremely appreciated. Thanks.
Yep he can write a simple batch script to run as a scheduled task.
shutdown -r -t 5
posted by damn dirty ape at 9:13 AM on December 9, 2008
shutdown -r -t 5
posted by damn dirty ape at 9:13 AM on December 9, 2008
Response by poster: Rebooting is far from ideal due to the fact many developers leave their systems compiling out of hours. Is there no way to do this without forcing reboots?
Also, the AD method only allows .msi, what if this installer doesn't come as a .msi?
posted by Whoop at 9:15 AM on December 9, 2008
Also, the AD method only allows .msi, what if this installer doesn't come as a .msi?
posted by Whoop at 9:15 AM on December 9, 2008
Response by poster: Oh, and we're already using WSUS although obviously they're not patched as quickly as they should be...but we don't live in a perfect world.
posted by Whoop at 9:16 AM on December 9, 2008
posted by Whoop at 9:16 AM on December 9, 2008
Right, but as a responsible admin, you should be able to say "every third sunday of the month is patch day, machines will be rebooted at 8am" or somesuch.
posted by Oktober at 9:23 AM on December 9, 2008 [1 favorite]
posted by Oktober at 9:23 AM on December 9, 2008 [1 favorite]
There are many ways to tackle this issue, it all depends on your detailed requirements and budget. My enterprise uses New Boundary's Prism Deploy for application management, there's also MS SMS. Both of those products can be a little pricey. If you're dedicated to doing it on the cheap and using GPO you probably want to look at a MSI packager/installer to turn those annoying exe installs into MSIs...Also don't neglect the wonderful world of scripted installs via vbscript.
In short you really need to sit down, document all of your needs and see what your options are from there.
AppDeploy.com was a great website for tips/tricks/howtos when my IT life was centered around application deployment. YMMV.
posted by wavering at 9:48 AM on December 9, 2008
In short you really need to sit down, document all of your needs and see what your options are from there.
AppDeploy.com was a great website for tips/tricks/howtos when my IT life was centered around application deployment. YMMV.
posted by wavering at 9:48 AM on December 9, 2008
Response by poster: And how do I force a reboot without going to every single PC to schedule it. I could do it via AD...but that only takes effect when you login. This is why I always stuck with Linux admin :-)
posted by Whoop at 9:48 AM on December 9, 2008
posted by Whoop at 9:48 AM on December 9, 2008
There's a difference between not living "in a perfect world" and allowing users to disregard basic security principles which, on Windows, call for the occasional reboot to install updates and applications.
For non-msi installs, there are a few ways to skin that cat. If they support command line options to make them silent or reduced UI, I've successfully used msicreate and msilaunch from this site to create simple MSI "wrappers" around other installers.
posted by JaredSeth at 9:50 AM on December 9, 2008
For non-msi installs, there are a few ways to skin that cat. If they support command line options to make them silent or reduced UI, I've successfully used msicreate and msilaunch from this site to create simple MSI "wrappers" around other installers.
posted by JaredSeth at 9:50 AM on December 9, 2008
Sigh.....
In a past life, I did software deployment. Group Policy is OK to deploy in a network of your size provided everything you install is in the form of an msi. As I am sure you are aware, not all vendors package their software as MSI files. This leaves you in a bind for about 80% of commercial software on the market today, unless you are into the error prone practice of repackaging software into msi files. I could go on all day about why that is a bad idea (besides being error prone, it's time consuming). From the jump, I recommend finding a different way to deploy software, but if you are stuck with group policy, I guess you do what you have to do.
Communicate the need to reboot to your developers. As they write code, they should understand the need for an occasional reboot. What developers do not like, in my experience, is when they are not told said reboot is coming. Give them enough advanced warning, and communicate it often. If need be, get your manager to talk to the dev manager. Obviously, all of this rebooting and deploying should be done off-hours so as not to impede the developer from troubleshooting a production issue during business hours.
Also, I recommend rebooting both before the deployment (to get a decent baseline) and after your deployment completes.
posted by PsuDab93 at 9:51 AM on December 9, 2008
In a past life, I did software deployment. Group Policy is OK to deploy in a network of your size provided everything you install is in the form of an msi. As I am sure you are aware, not all vendors package their software as MSI files. This leaves you in a bind for about 80% of commercial software on the market today, unless you are into the error prone practice of repackaging software into msi files. I could go on all day about why that is a bad idea (besides being error prone, it's time consuming). From the jump, I recommend finding a different way to deploy software, but if you are stuck with group policy, I guess you do what you have to do.
Communicate the need to reboot to your developers. As they write code, they should understand the need for an occasional reboot. What developers do not like, in my experience, is when they are not told said reboot is coming. Give them enough advanced warning, and communicate it often. If need be, get your manager to talk to the dev manager. Obviously, all of this rebooting and deploying should be done off-hours so as not to impede the developer from troubleshooting a production issue during business hours.
Also, I recommend rebooting both before the deployment (to get a decent baseline) and after your deployment completes.
posted by PsuDab93 at 9:51 AM on December 9, 2008
>Is there no way to do this without forcing reboots?
The problem here is do you really want an installer to run at random? Say Im working on a project then suddenly some EXE or MSI installer runs, now I lost focus perhaps it will reboot and I will lose my work. Your installer has a good chance of crapping out if it needs to make a change to anything thats running too.
Packaging an exe so it runs unattended isnt too difficult. For really badly written packages that dont let me just any switches for silent installs or anything I just wrap them in an AutoIT script. It'll press all the buttons for you. If you havent done much scripting you'll find that that doesnt have a steep learning curve.
If you want to do remote pushes, perhaps psexec, which is free, is the way to go. Even then you still have the problems listed above.
Seconding JaredSeth. You really need to be a bit assertive in this role. Its important to work out some kind of downtime that lets you do installs and updates, even if its 3am on Sunday.
posted by damn dirty ape at 10:25 AM on December 9, 2008
The problem here is do you really want an installer to run at random? Say Im working on a project then suddenly some EXE or MSI installer runs, now I lost focus perhaps it will reboot and I will lose my work. Your installer has a good chance of crapping out if it needs to make a change to anything thats running too.
Packaging an exe so it runs unattended isnt too difficult. For really badly written packages that dont let me just any switches for silent installs or anything I just wrap them in an AutoIT script. It'll press all the buttons for you. If you havent done much scripting you'll find that that doesnt have a steep learning curve.
If you want to do remote pushes, perhaps psexec, which is free, is the way to go. Even then you still have the problems listed above.
Seconding JaredSeth. You really need to be a bit assertive in this role. Its important to work out some kind of downtime that lets you do installs and updates, even if its 3am on Sunday.
posted by damn dirty ape at 10:25 AM on December 9, 2008
And how do I force a reboot without going to every single PC to schedule it. I could do it via AD...but that only takes effect when you login. This is why I always stuck with Linux admin :-)
Don't poo poo Windows just because you don't know how...If I had to schedule reboots for Linux I'd hate it too because I don't know how off hand, but a little searching and a little playing would teach me how. You too can learn Windows, it just uses a little different toolset now and then.
reboot.bat=shutdown /r /t 30 /c "You should reboot every now and then, it makes jebus happy"
run on each workstation
schtasks /create /tn dailyreboot /tr \\someserver\scripts\reboot.bat /sc Daily /st 23:59 /ru administrator /rp password
if you want to schedule these tasks remotely, use ldap and vbscript to dump your domains computer accounts, then use WMI to schedule a task
There are many ways to skin the cat. You just have to find one that works for you.
posted by wavering at 10:28 AM on December 9, 2008
Don't poo poo Windows just because you don't know how...If I had to schedule reboots for Linux I'd hate it too because I don't know how off hand, but a little searching and a little playing would teach me how. You too can learn Windows, it just uses a little different toolset now and then.
reboot.bat=shutdown /r /t 30 /c "You should reboot every now and then, it makes jebus happy"
run on each workstation
schtasks /create /tn dailyreboot /tr \\someserver\scripts\reboot.bat /sc Daily /st 23:59 /ru administrator /rp password
if you want to schedule these tasks remotely, use ldap and vbscript to dump your domains computer accounts, then use WMI to schedule a task
There are many ways to skin the cat. You just have to find one that works for you.
posted by wavering at 10:28 AM on December 9, 2008
The easiest way to do a one off installation is probably through PSexec. Dump a list of the computer names, then create a script to remotely install/patch on off hours. You may want to let your users know ahead of time.
FYI, most Windows update patches have a /norestart or /noreboot flag.
posted by wongcorgi at 1:13 PM on December 9, 2008
FYI, most Windows update patches have a /norestart or /noreboot flag.
posted by wongcorgi at 1:13 PM on December 9, 2008
psexec works well. for extra command line windows magic learn WMIC ('tis native) and/or powershell ('tis the future).
If you have a list of workstations in a workstations.txt file, you can run a bat file on your targets and then reboot reboot them:
posted by rye bread at 2:26 PM on December 9, 2008
If you have a list of workstations in a workstations.txt file, you can run a bat file on your targets and then reboot reboot them:
wmic /node:@workstations.txt /failfast:on process call create "\\server\openshare\install_stuff.bat" wmic /node:@workstations.txt /failfast:on operatingsystem where Primary='True' call Win32ShutDown 6remotely creating processes on computers will drop your network creds when on the remote machines, so the bat/software repos need to be in a read-only unauthenticated share.
posted by rye bread at 2:26 PM on December 9, 2008
I looked at WSUS, and decided it wasn't going to be the basis of my app deployment scheme because of the MSI-only thing. So, I have a honking great script called machine-update.bat. It's organized in stanzas separated by three blank lines so I can find my way around inside it. The opening stanzas look like this. There is still a bit of cruft there left over from when some of our workstations used to run Windows 98; I should clean that up one day.
The remaining stanzas all have the same basic structure:
This makes the usual result of executing the script a very quick check of all the zero-length flag files in the flag directory. If they're all in the same state as the last run of machine-update.bat left them, it takes about two seconds for machine-update.bat to complete.
Here are the first few installation stanzas:
Workstations run this thing from an AD startup script, so it runs with SYSTEM credentials. The occasional installer (Google Earth, I'm looking at you) won't work like this, and I have to do a bit of fartarsing about to trigger a second script that runs at logon time and uses psexec to run with admin privileges.
Because your workstations aren't rebooting regularly, you could just have them run something similar to machine-update.bat as a scheduled task, and you could set that scheduled task to run with administrative credentials and avoid the need for psexec.
posted by flabdablet at 3:45 PM on December 9, 2008
set flags=C:\StMary
if exist %flags%\frozen goto end
set dir=nul
if "%OS%" == "Windows_NT" set dir=
if not exist %flags%\%dir% mkdir %flags%
set root=C:\Windows
if "%OS%" == "Windows_NT" set root=%ALLUSERSPROFILE%
set desktop=%root%\Desktop
set startmenu=%root%\Start Menu
set programs=%startmenu%\Programs
set quicklaunch=%root%\Application Data\Microsoft\Internet Explorer\Quick Launch
set shortcuts=%desktop%\Shortcuts
set yes="P:\installers\stmary\yes.txt"
set rmdir=deltree /y
if "%OS%" == "Windows_NT" set rmdir=rmdir /s /q
set run=start /w
if "%OS%" == "Windows_NT" set run=start "Waiting..." /wait
set autoit=P:\Apps\AutoIt\AutoIt3A.exe
if "%OS%" == "Windows_NT" set autoit=P:\Apps\AutoIt\AutoIt3.exe
set sleep=ping 127.0.0.1 -n
set cls=@call :cls
if not "%OS%" == "Windows_NT" set path=C:\Windows\system;%path%
goto scuts
:cls
@echo.
@echo.
@echo.
@echo.
@echo.
@echo.
@echo.
@echo.
@if exist %flags%\pause pause
@goto :eof
:reboot
if "%OS%" == "Windows_NT" goto rebootNT
%windir%\rundll32.exe %windir%\system\shell32.dll,SHExitWindowsEx 6
goto bootwait
:rebootNT
%windir%\system32\shutdown.exe -f -r -t 2
:bootwait
%sleep% 20 >nul
%cls%
@echo Automatic restart failed.
@echo.
@echo Please turn off this computer by
@echo pressing the power button on the
@echo front of the system box.
:bootloop
@goto bootloop
The remaining stanzas all have the same basic structure:
:somefeat
if exist %flags%\somefeat goto nextfeat
%cls%
title Setting up some feature...
(code to set up some feature or install some app or whatever)
type nul >%flags%\somefeat
This makes the usual result of executing the script a very quick check of all the zero-length flag files in the flag directory. If they're all in the same state as the last run of machine-update.bat left them, it takes about two seconds for machine-update.bat to complete.
Here are the first few installation stanzas:
:scuts
if exist %flags%\scuts goto sshort
%cls%
title Creating All Users Shortcuts folder...
if not exist "%shortcuts%\%dir%" mkdir "%shortcuts%"
if "%OS%" == "Windows_NT" cacls "%shortcuts%" /t /g "curric\Domain Admins":f SYSTEM:f curric\Installer:f Everyone:r <>
type nul >%flags%\scuts
:sshort
if exist %flags%\sshort goto jre
%cls%
title Installing "Staff Shortcuts" shortcut...
copy /y "P:\Installers\StMary\staff-shortcuts\Staff Shortcuts.lnk" "%shortcuts%"
attrib +r "%shortcuts%\Staff Shortcuts.lnk"
type nul >%flags%\sshort
:jre
if exist %flags%\jre16011 goto twcli32
%cls%
title Installing Sun Java runtime environment 6 update 11...
set setupexe=P:\Installers\Java\jre-6u11-windows-i586-p-s.exe
%run% %setupexe% /s /v"/qn REBOOT=Suppress IEXPLORER=1 MOZILLA=1"
%cls%
title Uninstalling older Sun Java runtime environment versions...
%run% msiexec /qn /x {26A24AE4-039D-4CA4-87B4-2F83216010FF}
%run% msiexec /qn /x {3248F0A8-6813-11D6-A77B-00B0D0160070}
%run% msiexec /qn /x {3248F0A8-6813-11D6-A77B-00B0D0160060}
%run% msiexec /qn /x {3248F0A8-6813-11D6-A77B-00B0D0160050}
%run% msiexec /qn /x {3248F0A8-6813-11D6-A77B-00B0D0160040}
%run% msiexec /qn /x {3248F0A8-6813-11D6-A77B-00B0D0160030}
%run% msiexec /qn /x {3248F0A8-6813-11D6-A77B-00B0D0160020}
%run% msiexec /qn /x {3248F0A8-6813-11D6-A77B-00B0D0160010}
%run% msiexec /qn /x {3248F0A8-6813-11D6-A77B-00B0D0150110}
%run% msiexec /qn /x {3248F0A8-6813-11D6-A77B-00B0D0150100}
%run% msiexec /qn /x {3248F0A8-6813-11D6-A77B-00B0D0150090}
%run% msiexec /qn /x {3248F0A8-6813-11D6-A77B-00B0D0150080}
%run% msiexec /qn /x {3248F0A8-6813-11D6-A77B-00B0D0150070}
%run% msiexec /qn /x {3248F0A8-6813-11D6-A77B-00B0D0150060}
%run% msiexec /qn /x {3248F0A8-6813-11D6-A77B-00B0D0150050}
%run% msiexec /qn /x {3248F0A8-6813-11D6-A77B-00B0D0150040}
%run% msiexec /qn /x {3248F0A8-6813-11D6-A77B-00B0D0150030}
%run% msiexec /qn /x {3248F0A8-6813-11D6-A77B-00B0D0150020}
%run% msiexec /qn /x {3248F0A8-6813-11D6-A77B-00B0D0150010}
del %flags%\jre*
type nul >%flags%\jre16011
Workstations run this thing from an AD startup script, so it runs with SYSTEM credentials. The occasional installer (Google Earth, I'm looking at you) won't work like this, and I have to do a bit of fartarsing about to trigger a second script that runs at logon time and uses psexec to run with admin privileges.
Because your workstations aren't rebooting regularly, you could just have them run something similar to machine-update.bat as a scheduled task, and you could set that scheduled task to run with administrative credentials and avoid the need for psexec.
posted by flabdablet at 3:45 PM on December 9, 2008
Sorry, missed a less-than on that paste and one of the lines got screwed up. Here's that stanza again:
:scuts
if exist %flags%\scuts goto sshort
%cls%
title Creating All Users Shortcuts folder...
if not exist "%shortcuts%\%dir%" mkdir "%shortcuts%"
if "%OS%" == "Windows_NT" cacls "%shortcuts%" /t /g "curric\Domain Admins":f SYSTEM:f curric\Installer:f Everyone:r <%yes%
type nul >%flags%\scuts
posted by flabdablet at 3:53 PM on December 9, 2008
:scuts
if exist %flags%\scuts goto sshort
%cls%
title Creating All Users Shortcuts folder...
if not exist "%shortcuts%\%dir%" mkdir "%shortcuts%"
if "%OS%" == "Windows_NT" cacls "%shortcuts%" /t /g "curric\Domain Admins":f SYSTEM:f curric\Installer:f Everyone:r <%yes%
type nul >%flags%\scuts
posted by flabdablet at 3:53 PM on December 9, 2008
This thread is closed to new comments.
If your machines arent rebooting then you arent doing any windows updates, which is a big no-no. I'd also look at implementing WSUS and getting those machines patched ASAP. Especially with the new vulnerabilities we've seen in the past few months.
You can kill two birds with one stone here. Implement forced patching which will reboot, which will force them to log in, which will, you guessed it: install your software via script/AD/whatever.
posted by damn dirty ape at 9:09 AM on December 9, 2008 [1 favorite]