Patch Management Solution

Still evaluating, but I am seeing things that confuse me so I need unconfusing. It should be simple for those who use the product and own license already.

We need to replace SCCM with other product that will let us patch computers and keep software current, patched, security updates and so on.
We are a very small IT shop very understaffed. I do more things that I have time or space to list here, so it's got to be simple and with the possibility of some day automating at least parts of it.
I think Patch Management can do at least the last part.

Here is what we need to accomplish, can Symantec's Patch Management do these, and if so, exactly what PARTS of this whole suite or pile of product and plug-in do we need to do these things. We own nothing except SEP and that's not even related. NO, we don't own the notification server or any parts or pieces of this whole process here.

The list can this product, PATCH MANAGEMENT, do these things:
* Tell us what computers have which patches or security updates, etc. or which are LACKING same?
* Push or roll out patches and security updates to computers that need them?
* Tell us which ones were successful, and which ones FAILED? (and be accurate?)
* Let us patch computers or groups of computers of our choosing - meaning push or roll patches to a small test group of computers we choose, then push or roll the patches out to computers maybe an office at a time, or 1/4 of our comptuers today, 1/4 tomorrow and so on.
* Let us SCHEDULE the patches for night or weekends?
* Let us choose to skip a patch if we find that there's a bug or problem that may break something here in our case, MS doesn't always pull bad patches right away?
* Let us push a newer browser - real life example we have a couple dozen computers still running IE9, will PM let us push IE11 to these computers?
* And finally - Can this product, PATCH MANAGEMENT, SUSPEND BITLOCKER BEFORE ANY UPGRADE OR PATCH.  If Bitlocker isn't suspended it really has a cow and users have to call in for a long string to get the computer unlocked because BL detects a change, etc..
We have found that if it's not suspended that if the patch requires reboots, the computer reboots, then goes to the bitlocker PIN screen and just sits - user comes in and puts in the PIN, the rest of the patch applies, reboots, etc. and this really messes up a Monday morning.  
(Yes, we require secure desktops with encryption and PIN so please don't argue the merit or need of Bitlocker with a PIN, etc. - that's a done deal, nothing can change that now and frankly, I'm just the messenger so no use covering that. Thanks for not telling us we don't need to be using a PIN.  ;-)   )

 

IF Patch Management can do all of that, exactly WHAT parts of all this whole server system do we NEED to do that?
This seems to be really modular and based on or built on other Symantec products, and I can't seem to find what we need to patch computers, push things like IE11 to computers that still have IE9 (don't ask), and tell us what needs what, and let us patch in groups as we need.

We need to push apps now and then, or even new versions of apps we have - I have a funny feeling this won't do that, though.........
 

Thanks.

Yes to everything.  Something things not exactly out of the box but I'm already doing all of those things.

There is no native anything for Bitlocker but as you're aware Altiris is a script deliver engine at it's heart.  Can you script tasks to perform those Bitlocker needs?  Is that something that SCCM and MBAM and WSUS do already?  If so then it's just a matter of reproducing those scripts and delivering them to the computers in question.  Again, THIS really won't be out of the box and you'll have to get creative, but if it can be scripted then it can be done.

Also, are you using MBAM right now?  Then you're aware that it's integrated into SCCM and without MBAM then your users will be able to turn off Bitlocker at will.  If you wish to not allow them to do so then you'll want to pay attention to the near-future release of Symantec Endpoint Encryption.

the CMS (Client mgmt suite) comes with Patch management and can handle all the above requirements except suspend bitlocker.  You would have to schedule a script or something to do that.  There is no MBAM integration into Altiris/Symantec.  You can create filters to group any number of machines you'd like (patch testers group 01) etc.... 

I'm not sure Patch Management Solution will let you upgrade IE, you might need another component of the Client Management Suite, Software Management Solution, to accomplish that. Traditionally Patch Management has been to patch existing applications, not upgrade them although this has been relaxed. One of the key features of Patch Management is that it scans PCs for vulnerabilities and won't distribute them to any computer that doesn't need it. There are reports and screens that show what's required - so after Patch Tuesday I can go to the Compliance by Bulletin screen and it will only show me Bulletins that are relevant to my organisation. I can then download and stage them to a Target containing my test group and then increase the computers in that target as I go. Any patches I wish to pull I can go into the Bulletin in Patch Management and deselect the individual patch from the bulletin. Patch Management can be configured to automatically disable superseded Patches. Separate from the targeting of patches is the application of them - this and the reboots can be scheduled; this too can be different for different groups of PCs. You can even schedule the install for, say, 2030, and then they will just be staged on the client and you can trigger the install manually via the agent when it suits you.

They don't tender version upgrades through patch so long as the previous versions are still supported by the respective vendor.  IE, though, is its own beast and is likely best approached with a plan and a custom package.  Otherwise it will reach out to the Windows Updates site and patch itself at installation time.

And I think you'll need Software Management Solution to run scripts to manipulate bitlocker.

Yes, since Patch has no pre or post- patching script capability you'd need to use Software Management Solution to deploy your script and then trigger the patch event from the command line and not use the standard patch policies.

No MBAM, and no, users cannot disable or manipulate Bitlocker. That's handled via GPO and Active Directory. It's integrated into AD and they used a PIN and it's TPM enabled. Group policy controls what they can or can't do - and we have it set so they can't do squat except get past "the bitlocker screen" and then log into windows.

And no, SCCM doens't do the suspend, we had to run a batch process, basically it's just a single command line like a batch file - SCCM is told to run that command, then run the updates/installs/patches. It's not native in SCCM. (*unless that has changed with 2012 but that won't matter as SCCM is going bye-bye soon. I think that 2012 SCCM actually did do that, 2008 did NOT. )

To clarify - we aren't looking at the entire suite, although I'd LOVE it if we did. I have to assume it's just too costly - I mean the underlying server part has to be a biggy, then  each other item is an individual plug-in we have to purchase separately - I doubt we'll be getting much beyond Patch Management, although from these responses it appears we may be forced to.

We are looking for replacement for the SCCM patching and updating part AND a way to push software installs (inventory would be great, things get lost, things appear on computers that should not be there although I do lock things down a lot with SEP's application control).
We need a good way to keep the 300 computers we have patched and up to date for security fixes, patches, updates, etc. and push software if needed.
For example - Flash, JAVA, Google's Chrome browser, Acrobat Reader (although that's going away too thankfully and is being replaced by Fox-It reader), And Windows of course, and Office.
We need to be able to push out patches, security updates and fixes and so on for those products.
AND - push software installs and push software updates or upgrades.
We recently had major issues with Dragon Naturally Speaking - a version they told us to use was junk, failed constantly, so they said here, use this one instead - for that we'd need the Software Management Solution, correct?

So at first I was seeing conflicting information or replies, now that I've read further, it appears that Patch Management can NOT run anything BUT patches, there's no provisions at all for passing a single command line, just one little line to suspend Bitlocker? (uh, one reason we need to do that is because users can't, nor can they re-enable it later!)

No, as far as this -
>>but as you're aware Altiris is a script deliver engine at it's heart<<

No, I still know extremely little about Altiris but I knew *nothing* about it at all until I was told to try to find a replacement for SCCM's patching/updating abilities.
I had heard the name, but had no clue what it was, who owned it, what it did, and still mostly do not.  This is new. It would be like asking me to perform operations on some HP Mini - LOL - I wouldn't even know how to get into one. I know SEP inside and out, this product is as foreign to me as trying to speak Chinese.
I guess that's why I'm asking such basic stuff-  I have no clue what this thing is or does, but need to learn FAST - boss want's a decision this week!
Is this a product absorbed by Symantec? Or their creation? Or an acquisition they have integrated into the fold and modified for their needs? (nothing against any of that, we would have not had SAV-CE and then SEP had they not grabbed Intel technology years ago. )

So, to get this straight, Patch Management can NOT:
Install other software, it only patches that which there are security fixes or patches for.
Run a simple command, Run a script, Run a batch or command file
Upgrade IE from 9 to 10 or 11 (even though technically speaking IE10 and IE11 ARE SECURITY PATCHES for Windows and are not software installs or upgrades, please see image below - it's a security update for Windows according to Microsoft, not an installed application. check your Windows 7 control panel.)

To install apps, Andy seems to answer that with this:
>>I'm not sure Patch Management Solution will let you upgrade IE, you might need another component of the Client Management Suite, Software Management Solution, to accomplish that. Traditionally Patch Management has been to patch existing applications, not upgrade them although this has been relaxed.<<

We would need Software Management Solution, that makes sense and I'll take a look at that. We'll see how pricy that is, and what it can do, too - we DO need to push applications - SCCM used to do that when we could figure out how and force it to. SCCM faltered a LOT at software installs or pushes.

Andy also touched on something I'm trying to get my arms around - he mentions it here:
>>Separate from the targeting of patches is the application of them - this and the reboots can be scheduled; this too can be different for different groups of PCs. You can even schedule the install for, say, 2030, and then they will just be staged on the client and you can trigger the install manually via the agent when it suits you.<<

Targeting - I assume that's saying ok, we have patches A, B and C, and computers 1, 2 and 3, where computer 1 needs A, B and C, computer 2 only needs B, and C needs nothing - is that about right? Targeting - that would be Patch Management itself figuring out what patch or update to shoot at what computer?
Staged on the client -  The patch is copied to the client, staged, its' there and ready, just not applied - because you have set the install for the future.  It's there, but not installed because 2030 isn't here yet, but you can then later trigger the actual install manually per computer or group (or set the install date for just 7 days away and hit that the next weekend).
Could this be useful, perhaps for a major patch or fix that takes a lot of time to get pushed out to 33 remote offices across the WAN, too late to actually let it INSTALL because we are coming up on production hours - is that a scenario where that may be used?

I think I've gotten close to the basics thanks to all the responses that took into account I'm a total beginner with this product and Altiris in general. I knew nothing about it until 3 or 4 weeks ago and frankly still know very little about it. I'm more the SEP expert, network security administrator - so I guess it makes sense this would fall to me to investigate, trial and see if it will work for US, evaluate, etc. .

I've not done anything with it yet but would really need to get a true actual live TEST going -we have computers that are months behind because the one person who knew anything about SCCM is gone now, no one else knows it, and it never really worked anyway. NEver has.
So I'd like to actually pick 6 or 10 computers, figure out how to get at least THOSE patched and current, then can tell the boss yeah it works, but know HOW to do it!
There appear to be several things or stages or steps - but I'm getting there.
At least now I know what it can and can't do, and its' all reasonable.
Big thanks for those responses thus far!

Oh, IE 10 - it's a patch, not an application install - check your Windows 7 control panel    ;-)    - it won't be listed until you check display security updates in the programs and features part. It might fly if that is the case...........???????

I'm pretty sure Patch Management won't treat IE10 as a patch - I can't find it in my system. Symantec bought out Altiris a few years ago now. I'm not an expert on pricing but I think that usually one of the solutions, like Patch Management, will cost around 2/3 of the Client Management Suite containing Software Management, Inventory and Deployment Solutions. You'd use Software Management Solution to upgrade Dragon. Targeting is you figuring out what you want patched. Patch Management decides if the PC needs the patch by performing an assessment scan. So even if you target a patch at a PC Patch Management won't put that patch anywhere near that PC if it doesn't need it. If you set a Policy for a group of computers to only install Patches in 2030, so you can install them manually, you might get into problems if you then want to try and automatically trigger them as a group say at a weekend. Each PC should only have one Policy applied at a time so you'd have to make sure the PCs didn't get the 2030 policy but did get the weekend policy then change that back afterwards. You could have a number of 2030 polices, one for each group that you could change as you wanted to patch each group of PCs. You don't need to worry about patches installing during production hours, you usually put a time on the Policy for them to install - we do it at 22:00 every night and our PCs shut down at 00:15, which gives us our reboot. Any on a slow link that don't get downloaded by 22:00 would install the next night at 22:00.

ShadowsPapa, are you working with a partner on this yet?  Unfortunately nobody in here can discuss pricing with you but like almost everything software there is a wide range of pricing available.

If your goal is to replace SCCM then you'll really need to consider Client Management Suite which will allow you to do software delivery, patching, and system imaging (among other things).

Regarding IE10, we're both correct.  Yes, Windows views it as an update but it's really a new piece of software.  Check out the IEAK to customize the installation:

https://technet.microsoft.com/en-us/ie/jj631564.aspx

 

I understand pricing and yes, we have to work through a reseller, government contract and all. We can't even buy directly from vendors as it has to come from an "approved vendor". (and sometimes oddly enough that means we may pay 1/3 MORE than buying direct but that's another issue entirely)
Just musing, and wondering to myself how it will all come out as being government we don't have a great budget for IT at all, sad to say.

ONE reason for us to get rid of SCCM - it was like having a Swiss Army knife when all you ever needed was a cork screw and a screw driver. The Swiss Army knife has all that and more, but hey, they are limited and clumsy to use and don't do as well as a nice Snap-On screwdriver or a cork screw made specifically for wine bottles.
And we used maybe 10% of SCCM - the parts we did use didn't work out that well. So why buy a big semi tractor when all we need to do is take our fishing boat to the lake?

We need to -
Patch and keep software secure/safe obviously - patched and current as far as security threats and so on.
Roll out new software now and then, at times install new versions (Dragon - needed to remove 1 version and then install a xx.5 version, even SCCM had a cow trying to do that)
Some sort of inventory-  not deep and massive, but what is the computer name, model, serial number, who is using it, where is it, what SOFTWARE is on it, what VERSION of that software, IP address, etc.  Handy would be last reboot time/date, last login time/date and who, that sort of thing, but really deep deep inventory isn't needed, nice, yes, of course.

Image - no, as much as I'd like to, we never used SCCM for that and recently gave up Ghost as the person who was hired to take care of images is using the Microsoft processes to create the images and they are done manually as computers are brought in or are repurposed. We don't keep images so current that we'd need that anyway. We aren't that big and frankly, our WAN would not handle much of that. We don't have the manpower to keep images up to snuff even on a monthly or quarterly basis.
There used to be me and 2 others in the networking and server and security areas and 3 helpdesk people. Now it's just me - and 2 helpdesk people.
So where I was all SEP and security, high-end buck stops here sort of things for server and desktop and I was backup for LAN/WAN, router, switch, etc. now - I do everything except helpdesk but since those two are fairly new - uh, guess what............
We simply don't have people or time for the nice stuff.
We need to patch, install/update and inventory.
I also handle group policy and administration of software that allows such thngs, and handle scripting like the login scripts, and doing magical things others can't figure out how the heck to do. I'm the "yeah, I can do that, give it to me" person when all else fails.

Anyway, thanks for all the information so far. 
Now I have to figure out what I messed up or did wrong for a patch I thought might go out last night to a group of computer - but it failed for all of them.
As a TEST, I chose something much needed - Acrobat Reader critical update from the last few days.
I right-clicked and downloaded it - it said 100% success there, it was here and ready. So I chose to apply that to our sorely out of date jobclub computers which our clients use, (usually disabled or handicap people we help look for employment and get training for same, etc., )
The Patch Management says that those computers range from 1% compliant to about 40% compliant and that they are also missing some of the stuff the other person supposedly had SCCM patch. We're missing patches SCCM was supposed to have pushed to those computers. an average of only about 35% compliant is NOT a good thing. I have not yet checked to see how the employee-used computers rate! I bet they are also lacking things from months and months ago the way things are looking.
Besides wanting to evaluate and trial this product, I'm really hoping I can figure it all out - and that we can get it as I see this as an emergency - we need to get these computers up to snuff and fast. We have state rules we have to comply with and 30-40% compliant and patched, some lacking patches from almost a year ago, will not make some people up high very happy.
I thought I had it set up to go to those computers during the "maintenance window" - 6pm to 6am this morning.
So far all I know is it failed for ALL of them. Don't know why, but it appears this is a lot more complex than simply saying hey, download this, apply it to this group of computers, schedule it for this window tonight - now go do it.
Ah, much to learn yet

PS - our IT department is tiny, like I said. We have something like 300 or so computers, a couple dozen servers which I patch manually due to some problems in the past with the automated patching of servers, and - we have 34 LAN-to-LAN offices and 3 or 4 offices with just 1 or 2 computers/people that connect via VPN client.
Only part of the people work here and are local to me, most are out in remote offices all around the state, from corner to corner.

It's very hard to keep track of what computers are where, and what they have on them.
I was recently asked what version of Flash we used here - my response? How many versions have been released?
Same for Acrobat Reader, (it's going away although about 1/3 of our computers still have it). I bet we have 2 or 3 versions of 10.xx and even 2 or 3 of 11.xx
IE? Well, we have 10, 11 and yes, still some 9
Who has what version of what? Ya got me there, I have no idea and no good way to find out.

We are government - so yeah, we have to ask permission, get bids, buy from approved vendors or resellers and if it's over $xx, it's even tougher.
So I need to sort of know this product inside and out, prove it works, will work, justify it, etc.
Knowing just what each little part or plug-in does or does NOT do is a major help, thanks.
 

I'd suggest that you read this thread:

https://www-secure.symantec.com/connect/forums/altiris-71-testing-patch-remediation-center-test-group-not-my-production-group

As far as your Maintenance Window... that's an actual thing that will supersede your normal policy schedule.  If the computer is not on or otherwise available during that window and your patch agent policy is configured to only deliver a patch at a time inside that window then those clients won't get the update.  Personally my workstation patch policy is configured to attempt to install patches daily at 0300, 1100, and 1700 plus an 8 hour reboot countdown.  We're a 24/7 shop but all machines aren't on at the same time.  And I do NOT use Maintenance Windows for anything.

Wow, thanks, I'll definitely read that. I just learned something new with your comments. OK, will take that into consideration. I thought at first that was cool - any time at night when we aren't here, but if you are suggesting that's not really all that great in all cases, I need to look harder at that.

We are of course union - we have set work hours (save for some management who may be using VPN from home, here on weekends, or here late at night)
The "jobclub" computers I mentioned I tried to test on aren't used after 6 - in fact, the user IDs that are normally used on those by our clients are restricted from login after 6pm.
(maybe I'd better use that as a clue and see if the computers themselves have any restrictions)
Anyway, nothing ran on them - the update failed for all 31 of them or whatever it was.
My guess is that I missed a step. Or, didn't check a box or left something out I have to do before anything can actually deploy, as I call it.

I spoke with our IT head - my supervisor, and assuming we can afford/it's in the budget, we agreed that the software management part is likely a need for us to roll things out that aren't patches or security issues. So far, Patch Management, the software management so we can roll out apps, install/upgrade outside of patching or fixing, and depending on costs  (which hope our rep and reseller can help us with) the inventory parts as wow, can that piece really give details.
So far, even though I'm not up to how to make it do even just one single fix for Java on a small group of simple computers not used by employees and the time I tried failed 100%, I still feel this is good stuff and well worth trying hard to make it work and see if we can get it in here.

Back on another thing - suspending bitlocker with a single command line -  uh, any comments on this part here?
Any chance of having this pass a single line then launch the process of patching or installing the patch/whatever?

The trick with troubleshooting these things is to start with one patch on one client. The Java8-65 Policy you've shown needs enabling. So, can you see the patch on the client in the "Software update" tab of the Symantec Management Agent? Has it run and failed, just not run or isn't there at all?

As I stated earlier Patch has no capability of running a pre or post script so you'd need to use Software Delivery to deliver a script that would do the follow:

1.  Temporarily disable Bitlocker for a single reboot (however you'd do that)
2a.  Run "C:\Program Files\Altiris\Altiris Agent\Agents\PatchMgmtAgent\AeXPatchUtil.exe" /Xa /q /reboot  (this will install all pending patches and reboot the computer if necessary)

OR

2b.  Run "c:\Program Files\Altiris\Altiris Agent\Agents\PatchMgmtAgent\AeXPatchUtil.exe" /Xa /q
3.   Issue a command to reboot the computer regardless (this is a better option)

Remember, though, that just like WSUS or hitting Windows Updates this in only one pass and likely on computers that have not been patched regularly you'll require multiple passes to unlock prerequisites in order to present additional updates.  Also, installation of new products (Office, IE, Skype, whatever) will present additional updates as well.

As far as modifying the batch file as you highlighted that would only modify that ONE PARTICULAR batch file which is really just the command line to install that ONE update.  Unless you're going to modify every update that gets delivered every month (50+) and the re-running of the Bitlocker disable script over and over is not going to fail and give you strange error codes then knock yourself out.  However, it's not something that *I* would want to do.

Also, Andy's right.  Your screengrab above shows that that update is not enabled.  You'll want to toggle the On/Off option at the top right of that screen (not shown in your image).

Hmm, this has gotten actually more confusing and complex.

At least with SCCM (we didn't use WSUS as such that I'm aware of, unless the prior person who used to run SCCM did but there was never any mention of WSUS in all of the years I've been here other than earlier it was said "we don't have a WSUS server".
Anyway, when the updates/patches come out for, say, just to be simple, Microsoft products, it sometimes required 2 or 3 reboots - SCCM would take the patches from something like "patch Tuesday" and we'd push out the MS updates and patches. The computer may end up rebooting, then continue with more patches, then reboot again. This was not at all uncommon even with computers that were pretty well current - meaning only a month had passed.
That's one of the two reasons why Bitlocker needed to be paused part of the updates would install, the computer would reboot, then Monday AM 300 users would come to work and see their computers sitting at the Bitlocker boot PIN screen.
They would enter the PIN, get into Windows with their normal domain/Windows ID and password and find the computer really slow as it was continuing the update/patch process, then half an hour later (or whatever, just for example's sake) it would reboot again!
So we suspended Bitlocker, the first updates/patches would install, the machine would reboot, go back into Windows and continue - and if it needed a reboot it would do so............ by the time Monday came around the computer was ready to use with Bitlocker enabled again.

You all make it sound like we can't do more than just a patch or update at a time while SCCM would keep the patches as long as we didn't retire them, it might be able to push 2 or 3 months worth the next time that poor computer came onto the network again.  It almost sounds like you can't say - ok, this computer is 2 or 3 months back, it needs all of these, and have it create ONE single job that would do that?
SCCM could do that, just don't expire the patches too soon and next time the computer was online during a normal SCCM patch push if it had missed them last month it got last month's and this month's patches.

It sounds like there's a whole lot of manual babysitting and individual jobs that need to be created. We've never had to do that before.
We just have said ok, here's ALL of the patches, Windows, Office, etc. and they'd roll out. No having 50 different patch jobs.

Would this product force someone to be constantly creating little patch packages that need to be pushed, and if a computer was offline for a month, they'd have to manually create something just for that computer that was way behind?

We routinely have people ignore us and leave a computer offline, or perhaps someone is on vacation or family leave, there's a power hiccup, the PC gets rebooted and sits at the Bitlocker PIN screen and thus can't get updates....... are these going to require special attention each time?
(getting people to listen to IT and leave computers online, or on the network, etc. is like herding cats, although having 5 cats myself, I find herding cats to be far far easier then getting people to pay attention to IT)
 

There's simply no way to ensure all computers are on the network when needed - 1/3 of our computers are notebooks and may not even be online over the weekends, when we normally push things out. They get hammered when they next come online but they were WARNED.........
Will this fact cause us more work? We are operating at about half of our IT staff and the boys that run the state as far as IT rules say "no, you can't hire more people" so we can't move to product that requires half of a person's time.
It needs to be pretty automatic.

Well now you're imagining things because I didn't imply that nor would anyone actually use a product that works in the way that you're suggesting.

Patch Management in Altiris is policy-based.  Meaning, you enable something and any time a computer that is in a group that the policy is applied to it does the policy's action.  So over time clients will adhere to the shape of the environment that you've prescribed.

No, Altiris Patch does NOT work the same as Windows Updates or WSUS (and I have no idea how SCCM handles patching without WSUS).  It does take more time as there is no "evaluate immediately and present all my outstanding patches immediately".  What I AM suggesting is that there effort required at the outset but once clients get to that standard that you've defined it's simple after that point.

No, these offline clients won't require special attention every time unless YOU define patching to only happen when these machines are likely to be offline.  Frankly I'd recommend that you patch during the day when these computers are likely to be ON and in-use and don't force a reboot if your users are already conditioned to restart their computers nightly or some other measure of "frequently".  Or, patch and pop a countdown timer and have them reboot at the end of the business day.

After a few days of this, initially, then everything will be caught up to your standard (based on what you have defined in the Patch catalog).  Especially since it sounds like you have literally no idea whether or not your computers are patched or up to date or whatever.  If that last statement is true then I'd also suggest that your previous process was not working and it's not something that you'd be best seeking to reproduce with a different toolset.

Well so far, I've not found anything in the documents that explain what that example screen showing the existance of batch files was all about, or even really how to use it, so I'd likely not even touch that since there's no good documentation for that piece (that I've seen so far reading a few hundred pages) and with your comments here, yeah, forget that stuff as what we do has to be pretty much automatic, hands-off, autopilot. We can't babysit and modifty things every patch that's needed.

I suspect I could through a group policy, script or scheduled task that was pushed via policy, suspend Bitlocker so we'll consider that sort of to the side for now. It's likely if we do go with this product we'd get the software management piece with it anyway, we have a pretty big need for that as we've been talking lately.

Thanks for filling me in on what those batch files do/are.

And Andy - thanks for catching that-  I was certain I had done that, however, I also find I have to get used to actually saving or applying things, just exiting or moving forward doesn't necessarily save changes, which is a GOOD thing honestly, and I've been unable to spend more than 5 or 10 minutes at a time with the product trial anyway, but hopefully that will change. I've spoken with our supervisor about the crazy numbers of interruptions and stuff being tossed my direction with 0 information so that I have to play 20 questions with helpdesk staff.
("Joe said he can't get to a school site"  uh, when did he last try? "last week", ok, I'll bite, what's the URL for the site?  "it's their local school"  and what exactly is the URL?  - silence, no response until they send me another message "Joe still can't get there" so WHE did he last try? Again, no response..... am I to check 6 different logs and 100,000 lines of log entries to find Joe out of 300 of our employees and what site he's trying to get to and guess what date he last tried?)
So hopefully I can dedicate time to LEARN this beast.
It's complex. Lots of steps involved to get a patch pushed, I wonder what it's like to patch 4 products if computers are 3 months behind?

Thanks to all for hanging in there with me. Just the fact that some folks here, Andy, High Tower, etc. are so excellent and kind is a big plus for this.

Excellent. And sorry, I was gone Friday and had 2 different browser windows open and was getting twisted up a bit. I also have a bad bad bad problem with ADD and sometimes read but miss lines, if anything causes me to not stay on track. So I have to sometimes go back and read 2 or 3 times to see - oops, I missed that line the first time.  Plus tons of time pressure here  - NOT your fault! So thanks for your patience. I get to running in hyperdrive and sound blunt and abrupt. Please ignore that. You folks here have been better than almost any other Symantec product support area and I'm not just saying that. The documents are better, the people in this area KNOW the product and aren't just guessing. I can tell that. I may not know the product at all but have the ability to sniff out those who are guessing or don't know a product.

Anyway, ok, that's very good and refreshing.  It appears, I'll try to digest this into terms I can deal with first thing Monday with all sorts of complaints because people aren't following directions here (yeah, I won't say more)
It appears as if the biggest struggle will be to learn the process initially, figure out each individual step needed for, say, 1 patch for 1 product. Once I get that down, I can add to that knowledge. A baby step first.
Then the struggle will be to get our computers at least close to current.
No, I did NOT know how far behind, or how current any computer or groups of computers were - I had assumed we were fine up to the point the other admin left and SCCM was no longer pushing patches. Boy, you know what they say about ASSUMING. BIG mistake.
This product if nothing else told me one thing - just the jobclub computers themselves, the ones clients use here, are running about 34% in compliance. OUCH. And some are as low as 5% or even 1% compliant. Holy cow.
Employee-used computers are a lot better - but we're still talking only in the 50-70% range and those are only that good because there were new computers rolled out in August/September and most of those were updated when put into place at the remote offices.
So you were right - I did have no idea, but because of this product's reports, which I LOVE LOVE - I now know and it's scary. I showed the boss and now he's pushing even harder for a solution.

Your last message above really helped me a lot - you nailed it. This here helps a lot - 
>>Patch Management in Altiris is policy-based.  Meaning, you enable something and any time a computer that is in a group that the policy is applied to it does the policy's action.  So over time clients will adhere to the shape of the environment that you've prescribed.<<

One other thing directly related to this and your recent post above - you mention updating during regular hours - when we tried this with SCCM, it literally killed our WAN. It saturated the pipe into this central office so badly no one could do anything. We finally had to throttle the "bits" service but it still presents problems when using SCCM - yes the BITS service on each computer would only take in xx amount of traffic but traffic from this central office to over 300 computers still plugged up this pipe here.
And - the way SCCM worked, it was the UPDATES that controlled the reboot. If a reboot was needed, the computer would reboot and then continue with more updates.
If I see the documents correctly for this - and what I've read here, I could control the reboots, meaning they'd get update/patch A today and if B can't be installed until a reboot after A, B will wait on that computer until or unless the user says ok, let's reboot.
That means that tomorrow that same computer has A, has rebooted, and will receive B?

If that's the case, how does one handle the complaint that "my computer is REALLY REALLY slow and I can't do anything"? Windows applying updates/patches can do that. And if it's an Adobe patch, then you can't use the product while the product is being patched.
How do people actually roll things out during production hours?
Don't get me wrong, I'd LOVE TO DO just that! That would settle once and for all this bit of people not following directions........... computers being offline on the weekend.

I'm going to have to go and read and learn how to apply something so that it's not based on "if the computer is offline during the scheduled patch run, it will never get that patch" and get around that oops it was off that day, they missed it problem we have faced for years.

The biggest hurdle now will be to get computers caught up which this product is indicating are missing things from 1 year ago - SCCM said "yes, I sent it and the PC got it" but SCCM never told us if it REALLY got there, and I'm finding that no, it got the job, the job was launched, but the job FAILED. SCCM doesn't tell you that.
I see this product CAN tell you that. That's big plus.

 

You'll want to use the agent's throttling abilities.  The agent itself will measure the available bandwidth at the time of action and then throttle file transfer based on the rules you define.  For instance, if you say use 50% of available bandwidth it will do that.  Every client will evaulate what's available and then will adjust itself.  For us I think that we have our workstations configured to use 25% of available during daytime hours, and then that ramps up to 50% after hours.

Patch installations all download and execute locally, no execution from a remote share.  The agent does a "checkpoint" download and will download bits as they're available.  However, once a third party process starts it's out of Symantec's hands.  Meaning nobody can control how a computer is going to act while a Microsoft update is running.  Again, Altiris is a script delivery engine.  The script and the binary arrives on the computer and the script executes to launch that binary.  Poor PC performance while updates is running is a Microsoft and/or workstation config problem.

Another way to mitigate WAN bandwidth issues is to configure Package Servers, or to promote a local client to a PS.  Once you define a Site by subnets and assign a PS to that site, other clients in that Site will look to that PS for their binaries and only the PS will pull those packages across the WAN.  This could help at your remote office locations and it works pretty well.  Again, bandwidth throttling rules can be defined for the Package Servers and that clients at those Sites.

If you were to open up those .bat files you mentioned earlier you'd see that all of the MS stuff is configured to /noreboot (or whatever the syntax is).  This way you put the agent in control of managing pending reboots.  You'll also want to put a GPO in place that suppresses the built-in Windows behavior of prompting the user that "updates have been installed, reboot your computer" nag balloon and just use the Symantec agent.

I've found in the last few places I've administered that patches are very well behaved between install and reboot. So I usually recommend not rebooting immediately after patching. Most places now force desktops off at night and laptops tend to get rebooted often anyway. The only circumstance in which you need multiple patch cycles is if one is a pre requisite for another but the second patch still won't install until your next patch schedule. Once you have your Policy set for your Patch schedule (I use 22:00 every night and 15.45 every Fri afternoon with no reboots) it should be easy to go into the Patch Management Center > Windows Compliance by Bulletin and right-click and download then right click and stage each one you need. Set your default Patch Target to be your test group then edit each policy to include more machines once you're satisfied with testing. Once you get up to date the "configuring windows" screen users experience at power on shouldn't take too long once a month.

We have people leave their computers ON (and on the network, meaning past Bitlocker PIN screen and into at least the Windows LOGON screen)
If our people turned them off when they left computers may be off for days or weeks. Our people are social workers who they dislike IT and dislike having to think or click something unless they want to click a link in the email telling them they won the European lottery.
The old jokes are true - we tell people to reboot or turn the computer off then back on, then say ok, what screen are you seeing and they say "my desktop" - yeah, they restarted the monitor.  If they have to think, they complain to management and we get told to stop.  We have to dumb it down to gradeschool level.
Otherwise we find some computers may be offline for days, weeks or like one that just came online - it was off since MAY. Imagine the issues there as the computer suddenly

Anyway, our only plan that sort of works is computers are to be left on, do not turn them off when you leave.
Notebooks - let's not go there.  In order to force notebooks to be rebooted EVER and I mean ever, I had to set GPOs that totally disabled sleep and hibernate otherwise notebooks experienced huge rates of network troubles and they assumed that closing the lid would fix all problems. So sleep and hibernate are fully disabled, not even available. Sleep and Hibernate are horrible on a network. If they do that and then move the computer around they were complaining of "network problems". Well duh.

So notebooks "generally" get rebooted, but only about 3/4 of them and that's because I have to assume they will ignore us and do whatever they want or whatever is convenient or easy. If they had their way there'd be no passwords, no PIN, turn it on and go. You should have seen the backlash when we did something that caused them to have to make 1 (ONE) more mouse click to print. They went directly to the agency management and said we were making it impossible for them to get any work done.
Yes, that's what I face.

Back on this product - I'm a bit unsure, almost confused - as you said you don't do reboots and yet Microsoft's own patches - either via Windows update itself or SCCM, causes reboots. It isn't a choice of the push from what I've seen - the patch triggers an update and then continues. I patch servers manually and I find that a server has to be rebooted in the middle of a patch, then again when the patch is done applying. Files are in use or the registry says the server requires a reboot and a patch won't apply until you reboot, then it applies, then it needs another reboot or two.
Does this intercept those calls for a reboot that are in the patches and prevent them?
When I say that with SCCM - and again I was NOT the one running it - I've never even seen an SCCM server screen - the patches and updates went out on weekends, almost always triggering a reboot - and sometimes in some cases there was a patch/update, reboot, update/patch, reboot, patch and a final reboot. It was required that the computer have A and B before it could get C.
Some things like certain other apps require a reboot as well, and if they see that the registry says the machine is awaiting a reboot, that patch or install won't even start until you reboot for after the other product patch.

How can this apply all of the 1 single patch if that 1 patch needs to reboot in between - and I don't mean the reboot that finishes the install of the patch, I mean the reboot that finishes the first half or third of that 1 patch before it can continue and finish, and then do the final reboot.
I'm pretty sure it wasn't SCCM that triggered a reboot as I see this with servers now and then when I do them manually - you have to reboot the server TWO times for ONE patch. If you prevent that first reboot - it won't have that patch's first part. So when would it install part 2?
And if a patch for the OS needs a reboot, then a patch for another product won't install because it sees that a reboot is required in the registry, how does that work?

I'm also still confused over how this thing can work since I see over and over people say never have more than one policy applied to a computer in a given patch cycle.

If a computer has been off and say it missed last month's JAVA or Acrobat Reader patch/update and now there's a critical Microsoft Windows OS update you need to push out fast, then a computer comes on, it's got the JAVA and/or Adobe patch policy and now a windows OS policy...........
OR, if a computer was off and missed the last Windows OS patch, and you have a policy applied to push that out, and now our ISO says we have 5 days to get the latest critical patch applied, so you put out another Windows OS patch policy - there are now 2 patch policies out there and applied.
And yet everyone says no, you can't - you can only do one policy at a time.

That can't fly for us - when there's a critical patch out there and the ISO offices says "thou shalt apply NOW and you have 5 days to do so" we have to do it.
Yes, we are waaay behind now but they have sort of looked the other way since our SCCM person left - that's about to end.
Normal is we have xx days to roll out security updates and patches, there's no way to do one, remove that policy, do another, remove that policy, as so many computers won't be on during a given patch cycle, we'll have computers that need a dozen patches, thus will have a dozen Patch Management policies waiting for them when they are turned on.

PAtches come SO fast now - there's not even 2 weeks in between, we can't just do "patch Tuesday" when you have JAVA, Adobe products, MS products, Google Chrome and so on with patches released - I could create a patch policy or more every week, literally.

So is it true that you can't have 2 or more patch policies out there for Windows updates/patches? You can only do 1 at a time?

I'm about to go look and see if the JAVA patch that, uh, well, someone didn't have turned on, actually applied to any of the JC computers last night...........after I enabled it.

I'm also confused about scheduling - if you set a policy for 7pm - and no end or stop - and a computer is off that night, how does that scheduling work? I can't find anything in the documents about that - how that works.
Do I need a start and stop time? If so, what about computers that are offline then? If there's no stop or end time - does it start at 7pm and just keep pushing to any computer that comes online for all of eternity?

the help in the product is just an echo of the documents and has no help related directly to the screen or what things mean in any detail. They just say to choose a schedule, but don't say why you would choose one way over another.
Why would I set a stop or end time? Why would I not? What about offline computers? If it's set to push for 2 weeks, then 15 days later a computer comes online, what then? There are no scenarios in the documents or help.

I'm sorry but I simply can't follow this comment.  You'll need to be more succinct and more specific about your questions.

If computers are offline then obviously they can't be patched and patches obviously don't completely apply until the computer is rebooted.  It's up to YOUR organization and its IT policies to ensure that computers are available to be patched and computers are rebooted.  This is not a technology issue.

Remember, "Policy".  If a computer is a member of a group and that group is targeted for an update and the computer is not online to apply the patch then the computer is made aware of the new requirement when it comes back online and it applies that patch at the next scheduled time.  None of this is a one-time action.

Why would you set an end time?  I have no idea.  Nobody does that.

1.  Define your patching group targets.  Workstations, servers, whatever you want.

2.  Define your patch schedule and assign that to the group(s) you defined.  Like I said above we have our attempt to install pending patches 3x/day in perpetuity against production workstations.  (Software Update Plug-In Policy)

3.  As new Bulletins are released you enable them and create Policies to target the patch groups you have defined

4.  Go have coffee and watch your organization slowly get into compliance.

Yes, that was some of my thinking as I re-read the post after a couple of hours of reading and some coffee to calm down.
I need to get into bullet points.

I had trouble finding where to see this - and likely could not find it again easily, but I DID find a spot where it stated that my attempts from yesterday DID apply a patch to 3 of the 32 computers I had chosen, after creating a "filter" that defined those specific computers. And after, uh, turning that policy on.

Today I created another policy aimed at just a small handful of computers. That should be easier to manage and check into.

 * In the process I did get a bit confused as the bulletin APSB15-25 said in the list that it applied to 18 of our computers and then I ran into the target stating 280 computers.
But if I am correct the agent will see that it does or does not need it and work accordingly.
I believe I can assume the target is all possible computers, need it or not?

I think I would be best off starting by defining commonly used "groups" of computers as I would call them, utilizing the filters so that I can quickly choose some specific computers or collections of computers for this sort of testing. I'd rather not redefine commonly used computer collections every time.

* So am I correct that filters are the way to think of collections of computers where you start with the larger whole then include or exclude specific computers or computers based on OS, servers or not, etc.?

* Is it ok to create multiple "policies" because we have so many patches to get out there, and I should not have problems if a computer or groups of computers may actually need say 10 of the patches defined by the policies - they won't step on each other?
There are many dozens of patches needed if you add up Microsoft OS, Microsoft Office, Adobe, Chrome, etc. - will going ahead and creating say a dozen specific policies for that many bulletins cause a problem if I enable them all at once - or am I getting way ahead of myself - referring to your points 2 and 3 above.

Agreed - I'll concentrate on specific questions, target priority needs and concerns, try to cut to bullet points.

Desktop patches are much simpler than Server patches. I've never had a desktop patch either at home or work that requires a reboot halfway through. neither have I ever had a desktop patch that has triggered a reboot. What you will find is that, because the patch installs have to use the Windows Installer service to install, the users may well get the Windows Update prompt to reboot. But they can defer this. When you are told " never have more than one policy applied to a computer in a given patch cycle" they are talking about the Policy that schedules the installation, I recommend every night at 22:00 and Fri afternoon at 15.45. You should only have one of these applied to any computer. If the computer isn't on at the time specified it shouldn't patch until the next time. Don't leave patches on for just two weeks, target them at a test group, then a larger group, then everything and leave it like that. But you can have as many Patch policies as you like applied to desktops at once, I keep all of them applied to all PCs once I have completed rollout so that rebuilt machines get patched with old patches too. Or get patched if they get an extra bit of software installed that requires patching. It's up to you to present to accurately present to management the conflict between up to date patching and lack of disruption, it's then up to them to decide where they want the balance. When you get a cryptolocker virus because your Flash isn't up to date that balance may change.

In the older versions of Altiris they called computer groups "Collections".  In 7.x that was changed to Filters as it's more descriptive of what the process of defining these groups... usually you start with all computers excluding computers that X, excluding computers that Y, etc.

The way that *I* do it is that I tend to bunch everything that's released on Patch Tuesday that's a Security Bulletin into one patch policy (I call them payload policies) and everything else that's a Windows Update into a different payload policy.  You'll want to keep the total number of updates within a payload policy to less than 100 as I've been told that problems can result otherwise but I personally have seen no evidence of that.  I name these payload policies something like:

2015 10 October - MSSB (shorthand for targeted groups here) - (policy creation date) - (month that policy is slated for production deployment)

All of that keeps things sorted neatly for me and at a glance I can see where we're at in our rolling patch test/prod scheduling.

I'll do something similar but for the other products that are updated much less predictably than the Microsoft stuff.  Like this past month I've created 4 policies for Adobe Flash Player all by itself, but I bundle both the MS and Adobe patches into a single policy.

You will wind up creating scores of payload policies and your computers will be constantly evaluated against their contents.  Computers that require something that's defined in one of those policies will then download the binaries and execute accordingly.  For sanity's sake, though, I'd recommend against putting the same updates in multiple different payload policies.  You really should fight to keep your design as flat and as simple as possible.  In 8 years of doing this I have been able to resist the constant requests of other people asking to patch these systems differently than those systems.  When challenged the arguments for such an approach always fall apart.

You will also NOT want to apply more than one Software Update Plug-In Policy against a group or filter of computers as the way policies work in this product is that the last one to get applied wins.  If you have two policies with different agent behaviors defined (schedules, etc) there is no way to reliably predict which behavior set will stick.  It's best to disable the built-in SUPIP, clone it, and apply those cloned policies against your filters as the default target is terrible.

Finally, you will need to remember that Altiris Patch is NOT like WSUS or Windows Update.  Those systems provide for a do-it-now functionality whereas this product tends to work a little slower and updates are delivered to clients instead of clients requesting them.  Factors that affect how quickly a client receives an update are, among other things, your filter update frequency, your agent check-in interval, your Windows System Assessment Scan frequency, your bandwidth throttling rules, etc.  MOST people who begin using Patch get frustrated as things don't happen immediately.  This is normal!  Just make sure that you've checked to make sure the policies are all enabled and targeted correctly and that solves 95% of the potential problems.

 

 

Have you read this: "Configuring Patch Management 7.1 and 7.5 for Windows?" http://www.symantec.com/docs/HOWTO56242

Yes, I have glanced through and am reading again the 56242 but as I've said with my "condition" it often takes reading something 2 or 3 times as each time I "get something different" from a document. It's printed and sits right between keyboard and monitor as are some other documents I found that are helpful.

The reboots being as a part of the Windows installer/patch process makes sense. I won't get hung up on the reboots then and see that I could handle reboots IF needed vis the product here.

* It's the scheduling policies that could be in conflict and not the "patch or update policy" that defines what it is that is needed and who to aim it at.
'When' it does could be a conflict, not 'what' it does, if I understand that correctly.  
I could see perhaps keeping two schedules at most so something small could be run out at a different time, maybe more quickly, but for now, especially testing the Patch Management, I can see just one and likely that's enough anyway for us.

I saw the default end or delete time on these and I have already changed the 2 week timeframe but believe for now I'll make it open-ended.

I will need to add a drive to the test server to keep downloaded patches as the person who built this included only a single drive - and the OS and app have most of that taken. (It's VM so it only takes minutes to do so)
* Any clue as to how much drive space is taken just in general - Microsoft Windows 7, Office, Adobe Flash, JAVA, Google Chrome for the most part. I know it will vary wildly with the numbers of products, numbers of product versions - any rule of thumb there?

>>MOST people who begin using Patch get frustrated as things don't happen immediately.  This is normal!  Just make sure that you've checked to make sure the policies are all enabled...............<<
*  Point taken. That's me.
As Andy pointed out in the first example, I almost made the same mistake on a second test - I have to turn them on or enable them. I need to watch that.

* My other thing to get through is the acronyms, definitions, etc. That throws me as this product uses different terms, names and the acronyms have me learning a new language. I believe I have "filters" and "policies" down now - I hope.
I hope NS = Notification Server.
But - SUPIP  (edit - never mind *this one*, as is done in journalism you had already used the long form then went ot this later  = Software Update Plug-In Policy)
But - still the question - is there a document of the common abbreviations or terms or acronyms?

My primary role has since 1990 been generically "computer security"-  currently Network Security Administrator so I'm guess that's why this has fallen to me.
After Monday when 3 people who should know better, one of them a manager, clicked a link in an email supposedly from FedEx telling them to download and print a "postal label" which caused a JAR file to start hammering the Internet one would thing that it might not be TOO hard to stress the importance of all this.
 On the other hand the manager who had clicked that same link wasn't very concerned and after 3 hours she finally asked "does IT want to come clean my computer". By that time I had created multiple firewall and IPS rules to block the critter's communications and finally a SEP application control rule that prevented the files from even being run or executed and then cleaned up all 3 computers - remotely.
That's where my problem is - "IT will just take care of it for us if we get something bad."

Thanks again - I feel I'm finally getting somewhere, it's making more sense and the recent replies have solved a lot of mystery.

We will be getting quotes for:
Notification server  - assuming this is what the core of these products is, and that this is necessary for Patch Management.
Patch Management - obviously needed for - patching/updates, security fixes.
Software Management (or whatever the correct term is) to roll out new software, installs, upgrades, etc. - not security patches.
Looking at the Inventory plug-in as we lack any good inventory tool.

 

Regarding disk space I'll give you the answer that everyone hates.... "It depends".  It depends on the OSes, the vendors, the products, etc that you plan on patching.  And how long you plan to keep those updates in your catalog.  Personally we have "all the common stuff" (redacted for OpSec) dating back about 5 years and we're using about 60gb for the Patch repository alone.  Add in the binaries for other packages you're going to deploy and there's your answer.  Probably plan on at least 200gb for your repository, if not more.

The nice part of virtual servers is that if you underestimate needs for drive space, it only takes a couple of minutes or a few clicks to "fix" it, but you need to be careful as if you ad space to a drive later, it's another file on the host, it doesn't just make the original bigger. Add drive size/space too often and you get a collection of files hard to manage and snapshots, etc. take longer.  But it's possible.

That's a starting point anyway.
As I learn the product and find what the computers really need or don't need, I can trim things down a bit - and as we convert to Fox-It away from Acrobat reader we can not download or mess with the Reader parts any more, dumping the remaining 32 bit systems will also cut down on the downloads. 

You gave the most honest answer you could and I expected that of course - but your numbers also have some meaning.

I've been going through the "Configuring Patch Management xxxxxxxxx" doc again - the one Andy mentioned and it's brought up a question but I think that question is likely pretty easy and will be in a different simple topic and not tagged into this one.

Thanks.

To the Connect Forum moderators/administrators:

I've been pondering this question for a while - how to mark this as solved as for the most part I got a lot of valuable information.
There will remain some questions, but there is enough here that I got a lot out of it, learned things, unlearned things that I had figured incorrect, and other information that led me to do more research and learn more than I would have had I not asked and these folks not responded.

My problem is now this - I believe BOTH Andy and High Tower deserve credit. There was no one simple solution, but between the two of them I got a host of valuable information not found in any "howto" or readme file.

I don't want to click and have the solution marked other than intended-  and perhaps in cases like this they go on never marked as solved, but for all the time spent I think both members deserve some credit for their time, efforts and responses, to be fair.
They did their best, both, and it helped a lot.
Nothing was incorrect, and sometimes there's not a simple black and white single answer - but still, a lot of time and effort was spent by them.

If there is any way, I'd like to see both receive credit for answering.

Maybe there is and I simply missed it........

I type this of my own accord, no one suggested it, my cats were not threatened in any way, neither who responded has asked for anything.

Hi ShadowsPapa,

The easiest way to give both Andy and HighTower credit for the most helpful answers is by clicking the "Request Split Solution" link at the bottom of any one of their comments. You'll have the option of choosing as many comments as you have found helpful. Then save your request and it will go into an approval. I'll approve the request and points for the solution will be distributed between Andy and HighTower.

I'm glad they were able to assist you and no threats were made against the cats :-)

Cheryl