Software Deployment

Stop, don't package an MS patch. It is one of the cardinal rules. If you still want to package it as an MSI method, then create an MSI wrapper which could execute the exe within the MSI. Why not use a simple logon/startup script to install it /silent and force reboot?

true. I could just do it by logon script. Thanks. Btw, any free msi wrappers? I'll go research myself on that question as well..

If you are talking about normal security patches and the like that Microsoft release every month or so, you should really look at Software Update Services...

Its an absolute must for everyone but the smallest of organisations.

I've seen many requests for help in repackaging MS patches into MSIs across the forums. I don't understand why people need to repackage when MS supply SUS for patch deployment. Can someone explain in which situation you'd need to create a wrapper MSI for the patch, instead of using SUS? thanks

true, like meastaugh1, I would also like to know...

SUS requires that you have a domain in place and IIS installed on the SUS server. Alot of people do not want to go that route, it also means purchasing another server. i work in the public sector for a school district and it took getting taken to our knees by the blaster virus to convince the powers that be for funding to buy a new server. I guess for some people it is just easier.

You do not necessarily need to have a domain in place to have a SUS server update workstations. Having a domain in place does, however, make it easier to force all workstations to look to a particular SUS server and update according to a schedule and standard.

There is a large environment I am at on a regular basis that does not have an AD domain, yet the workstations update from a SUS server. We simply took the registry changes that SUS makes to a workstation, and pushed them down onto machines via the login script. The changes that are made are found at:

HKLM/Software/Policies/Microsoft/Windows/WindowsUpdate

They look like this:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"WUServer"="http://your_SUS_server"
"WUStatusServer"="http://your_SUS_server"

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]
"NoAutoRebootWithLoggedOnUsers"=dword:00000000
"NoAutoUpdate"=dword:00000000
"AUOptions"=dword:00000004
"ScheduledInstallDay"=dword:00000000
"ScheduledInstallTime"=dword:0000000c
"UseWUServer"=dword:00000001
"RescheduleWaitTime"=dword:00000001
"AUNoAutoRebootWithLoggedOnUsers"=dword:00000000

The only downside is that a savvy user could undo the changes if he/she has admin rights over the machine.

The necessity for a dedicated server really depends on the environment. The SUS Deployment Guide from Microsoft discusses considerations, but never states that a dedicated server is required.

Craig --<>.

You do not necessarily need to have a domain in place to have a SUS server update workstations. Having a domain in place does, however, make it easier to force all workstations to look to a particular SUS server and update according to a schedule and standard.

There is a large environment I am at on a regular basis that does not have an AD domain, yet the workstations update from a SUS server. We simply took the registry changes that SUS makes to a workstation, and pushed them down onto machines via the login script. The changes that are made are found at:

HKLM/Software/Policies/Microsoft/Windows/WindowsUpdate

They look like this:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"WUServer"="http://your_SUS_server"
"WUStatusServer"="http://your_SUS_server"

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]
"NoAutoRebootWithLoggedOnUsers"=dword:00000000
"NoAutoUpdate"=dword:00000000
"AUOptions"=dword:00000004
"ScheduledInstallDay"=dword:00000000
"ScheduledInstallTime"=dword:0000000c
"UseWUServer"=dword:00000001
"RescheduleWaitTime"=dword:00000001
"AUNoAutoRebootWithLoggedOnUsers"=dword:00000000

The only downside is that a savvy user could undo the changes if he/she has admin rights over the machine.

The necessity for a dedicated server really depends on the environment. The SUS Deployment Guide from Microsoft discusses considerations, but never states that a dedicated server is required.

Craig --<>.



This is for mickycarty, who asked me via email for more information on how this can be done:

segment of the Novell login script which calls the .vbs:


IF MEMBER OF ".xxxxxxx.xxx.xxxxxxx" THEN BEGIN
WRITE "start v835732 ."
MAP ROOT T:=xxxxxxx/VOL1:UTIL\
#CSCRIPT.EXE T:\VP835732.VBS
#CSCRIPT.EXE T:\susreg.VBS
MAP DEL T:

the .vbs that makes the registry changes and designates a SUS server is as follows:



Set oshell = CreateObject("WScript.Shell")

oshell.RegWrite "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\WUServer", "http://your_SUS_server", "REG_SZ"
oshell.RegWrite "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\WUStatusServer", "http://your_SUS_server", "REG_SZ"

oshell.RegWrite "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\AUNoAutoRebootWithLoggedOnUsers", 0, "REG_DWORD"
oshell.RegWrite "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\NoAutoUpdate", 0, "REG_DWORD"
oshell.RegWrite "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\AUOptions", 4, "REG_DWORD"
oshell.RegWrite "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\ScheduledInstallDay", 0, "REG_DWORD"
oshell.RegWrite "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\ScheduledInstallTime", 12, "REG_DWORD"
oshell.RegWrite "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\UseWUServer", 1, "REG_DWORD"
oshell.RegWrite "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\RescheduleWaitTime", 1, "REG_DWORD"

Set oshell = Nothing


Craig --<>.

I looked for this reg entry in windows xp and did not find it at the location show here.

I have a windows 2000 server setup with SUS and need to push out updates to windows xp machines only.

Help please! Since i do not have a domain, What's the correct way to do this by patching the windows xp registery at each machine?

any help here would be great! Thanks for all the info.

JM

JM2004,

The registry entries are not there by default. They are generated on the local machine by Active Directory Group Policy. Since you do not have AD/GP, you will have to create the entries with a .reg file or .vbs. I posted an example further up in this thread.


Craig --<>.

SUSS (Software Update Service Standalone) 1.002 (FR 1a) is now available

http://kopbeen.europe.webmatrixhosting.net

SUSS is a robust – lightweight console utility with the following benefits:

* Easy Installation / Scheduling.
* Excellent for monitoring the status of ALL your windows clients.
* No Active Directory deployment / Group Policies needed for smaller clients.
* Import all your windows clients for batch checks.
* Export results in CSV output files.

FREE: Feature Release 1a has the following benefits:

* Force clients to check & download updates immediately

Greetings... Being new at all of this, and this being my first time working with SUS, thought i'd ask around...

I have followed the suggestions given here, and currently have 2 test AD's with different GPO settings that should be doing the same thing.

Here's the little speed-bump i've hit... as far as i can tell, nothing is happening aside from the restrictions that got set.

As i said... i am new to this... if there is any further information you would like, please ask.

Domnu,

I have run into this a couple of times, and it usually is because IIS's urlscan.ini is blocking .exe files. Take a look at Look at the URLScan logs (c:\windows\system32\inetsrv\urlscan).

Craig --<>.

meastaugh1
I've seen many requests for help in repackaging MS patches into MSIs across the forums. I don't understand why people need to repackage when MS supply SUS for patch deployment. Can someone explain in which situation you'd need to create a wrapper MSI for the patch, instead of using SUS? thanks

It seems that this thread is dead, but I will give you an example. I just ran into a situation where I need to deploy an MS hotfix to targeted computers. I do use SUS and anxiously await WUS. We will be deploying SMS at a later date, but until that time I need to deploy a hotfix that was issued by PSS OR I can deploy XP SP2. I am not ready to deploy SP2, and with SUS, you cannot inject hotfixes into it, only those downloaded by the SUS synchronization.

So, I too will be looking at an MSI wrapper or just using batch files to get it installed.

If anyone is interested, the patch is an update for CSNW on 2k and XP when using Office (specifically for me, Outlook) 2003 and trying to save an email attachment out to Netware servers gives 'read-only error'.


Nate

You can repackage hotfixes because I have done it......but its not pretty and MS don't like it.

Once a month we wrap the hotfixes in msi format and run them as custom actions with commandline paramaters and its fine. You just have to make sure that if a hotfix needs a reboot by default to make sure you reboot as required and place that hotfix at the end of the string.

I have just been informed that MS do not support deployment of Hotfixes by Active Directory.

Seems like a bit of joke that you can't use a MS tool to deploy a fix for their OS?

It is actually due to file protection and the inability to prevent updating files required by Windows installer with a patch. So instead of sending some out in MSI format and some in EXE format, they have decided for the time being to deploy all updates via an executable. I hear that this will be solved with Windows Installer 3.0, but that is only a rumor. WI 3.0 is supposed to be able to create "on next reboot" tasks for file operations with redundancy, currently that cannot be done. Just imagine a security patch for WI 2.0 that replaces the core files...like MSIexec.exe, it would most likely break WI if that were deployed via MSI. In the mean time, MS has provided us with slipstreaming and Windows Update as well as SUS.