/build/static/layout/Breadcrumb_cap_w.png

PATCH or DO NOT PATCH machines used for packaging with Windows Security updates?

Guys,

I have this basic question and would like to know what your Packaging team does. We use VMWare images for packaging purposes and i argue with my team that we should not patch(I am taking about MICROSOFT WINDOWS XP MONTHLY SECURITY UPDATES ) the machines that we use for packaging purposes as they cannot be called as CLEAN IMAGE machines...That is my opinion. My team wants to patch the machines with all the windows secuirty updates. Can you guys share what you guys do to your machines. Do you guys keep them in a different AD group so that the regular updates will not affect your packaging machines or do you guys does not put the machine in the network at all? I feel we need our machines needs to be on the network because some applications likes to connect to the internet for licensing issues etc. Please let me know what you guys do.

Thanks in Advance

0 Comments   [ + ] Show comments

Answers (4)

Posted by: anonymous_9363 16 years ago
Red Belt
0
At probably 90% of the clients I have worked for, packaging machines are built using a base build and are exempted from automatic updates. If that build includes, say, MS Office, then the packaging boxes will, too. Testing VMs, however, will reflect the installed client base as closely as possible. In the case of my current client, that means maintaining 4 test VMs. All packages must be tested on all builds, irrespective of whether or not the application in question is designed to be deployed at all sites. This ruling means that if a package is required on another site in the future, there are no (or at least fewer!) surprises.

My two cents...
Posted by: kkaminsk 16 years ago
9th Degree Black Belt
0
Most environments I work for patch the packaging environment because they don't want those machines to be a potential host for viruses. It's all about managing risk and having a machine to package on that undergoes patching can add management to the packaging environment especially when you are using virtual machines. I've seen environments put their packaging environment on a different patch schedule so that the packagers know when they are getting patches so that they can cook them into their images so they don't have to wait for the patches to install every time they fire up a VM. This is more secure but you do burn a fair bit of time having packagers update their images. Another technique would be to use something like Citrix provisioning server so that there would only be a handfull of images at the most that would need to be updated. I guess it can be boiled down to patching = security & extra management $$$ but no patching = less security and management $$$.
Posted by: samanta123 16 years ago
Senior Yellow Belt
0
Guys thanks a lot for all your inputs and we are also going to update our VM machines every month and take a snapshot after that. I really appreciate all your help.

Thanks
Posted by: reds4eva 16 years ago
Second Degree Blue Belt
0
IMO, a packaging machine should not be part of a LAN. If it is on the network, surely you would require virus protection and all security patches. Doing a snapshot would be a fricken pain in the behind.
We have a Dev LAN, so we dont patch any packaging machines, or VM images used for packaging. They are not part of the real network and have no internet access. They are a true clean machines, basically XP Sp2, installer 3.1 and .net, and thats it.. Testing is done on test machines on the real network, those test machines have a client image so are patched ofcourse.
If your packaging machine is part of AD and on the LAN, then imo they should be patched, including having virus protection,
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ