Deployment and Imaging Group

I need to prevent Software Management software install policies from running during deployment job task.  I have some command script task that are being stopped because of these policies kicking off.

There's no way to "prevent" policies from running, but there are a few things you can try.

1) remove the policy files before deploying the image.  While the system is shut down for capture (or deploy) remove the policy files from the system.  That way, nothing "saved" can fire while the deployment script finishes.  New files can come down granted, but nothing saved will fire first.

2) prevent communication for a time.  You can actually delay communication with the NS for a time, but unfortunately the delay is random.  <sigh>  It's configured in the targeted agent settings.  The delay though might buy enough time for completion.

3) call support.  We may have a file for you that can be used to further delay things.  I'll explain.

We've discovered that we forcibly start the agent and get things going as SOON as the system reboots.  However, we've also discovered that during MiniSetup, the services are not supposed to be running, and ours is.  What this creates though is a situation where tasks (and policies) are firing during MiniSetup, and messing things up.  For instance, let's just say MiniSetup is joining a workgroup, and at the very same time we're running a config task to join a domain.  We finish, MiniSetup freaks-out because the system it thought it was renaming no longer exists, and dies.

The fix was to not start the agent until MiniSetup does.  We have a file we may be able to give you to help you avoid this problem.

That said, it will keep the agent stopped, so no tasks will fire, OR policies.  But if MiniSetup is kicking off the task, it will buy you time there.

Best we can do for now.

I repeat, there is currently NO WAY to prevent a policy from firing at the same time a task is firing.  There is talk about doing something like this, but it hasn't been done and I don't know when/how it will.

Thomas,

You and I have discussed this in regards to the agent plug-in policies as I have go that out of my way just by forcing a fast install now other policies are getting in the way and I have a 50% deployment failure rate.  I have created a new case for this 03979990.

One thought I just had is there a way to create a filter or something that would look for a machine executing a certain job?  This way the policy should exclude the machine by the filter.  Once deployment is complete filter drops machine on update and then machine falls back into the policy.  Now this is not perfect depending on how often you are updating your memberships but could really help.

Second thought is there a script I could create as a task to add a machine to a Group that I could exclude from the policies then at end of deployment I run the script to remove from the Group?

I need something and I can't believe no one else runs into this.

For others reading this, I took the case and I'm writing up a ticket for Dev as soon as I complete this forum post.

Translation, if any of the others here have feedback, now's the time.  I can include this thread and your feedback into the ticket I'm taking to Dev and Product Management.  

I've gotten around some of this by doing a custom inventory for OS Install Date and then put all computers built within the last 48 hours into an exclusion list that our policies don't act upon.  It's not perfect but dramatically reduces the number of 1618 errors and such that we see when building new machines.  Reimages of machines with an existing DB record still is hit or miss.

Naturally this has its own set of drawbacks but it's really helped in a mixed NS/DS6.9 environment.

We do it the ASDK way. In all deployment jobs we run a task with a Task Server Script first to push the machine into a global exclude filter. Managed Software Delivery Policy Targets are all build by filters and the global exclude filter is in the exclude list of all of them. At the end of deployment we remove the machine from global exclude again by using the ASDK in a Task Server Script.

Option Explicit

Const APPFILTER = "{GLOBALEXCLUDEFILTERGUID}"
itemComputer = "%COMPGUID%"

Dim oCollectionManagement, oItemManagement
Dim itemComputer

Set oCollectionManagement = CreateObject("Altiris.ASDK.NS.CollectionManagement")
'Set oItemManagement = CreateObject("Altiris.ASDK.NS.ItemManagement")

ocollectionManagement.TargetServer = "%NSSERVER%"
ocollectionManagement.UserName = "%SymUser%"
ocollectionManagement.Password = "%SymPwd%"
ocollectionManagement.DomainName = "%DOMAIN%"
ocollectionManagement.Authenticate()

Call oCollectionManagement.AddInclusions(APPFILTER, itemComputer)
'wscript.sleep 120000
Call oCollectionManagement.UpdateCollections(APPFILTER)

And in the remove just change the last 3 lines.

Call oCollectionManagement.RemoveInclusions(APPFILTER, itemComputer)
'wscript.sleep 120000
Call oCollectionManagement.UpdateCollections(APPFILTER)
 

SaschaH,

Let me ask you as I'm not a vb expert it looks like the only thing I need to change here is the guid of a filter I create, correct?

Basically create a filter

Get guid of filter and insert in this location: GLOBALEXCLUDEFILTERGUID

Then update all policies to exclude this filter.  Is there an easier way to do this than updating every policy?

Also thanks for this as this is a great solution.  May I ask where in your deployment you place the first task?  Do you make it the first task even before booting pxe?  Or after booting PXE but before you start the SOI (or image) job?

You would need to change the filter Guid, and the credentials for connecting to the asdk components. We use special Tokens for that but if you are sure only the right persons access the tasks and jobs you could also put it directly in the task.

As for the policies, we use filters as targets in the policies. So we just have the global exclude filter as exclude in the other filters when we create them. If you ad the resources directly to the policies, yes you would need to exclude it in the target you build there every time.

We let it run after booting to PXE, it doesnt need a lot only an associated task server and the GUID of the computer its run on. It should even run before booting to PXE  as its running on the task server.

It sure is easier to implement in a newly set up environment where you can make sure filters or policy targets always include the global exclude.

SaschaH,

connecting to the asdk components

In regards to the ASDK I know what this is but I do not have or use it.  Will this prevent me from implementing the task solution you proposed if I don't have it installed?  I hate adding more complexity but I do need a solution to this until Altiris actually fixes this problem properly.

Usually the ASDK is getting installed with the SMP. You should have the ASDK folder and samples in your Altiris folder.

We implement it by using part of the sample scripts in a script Task in Altiris itself. But as it's a task server script you will have to install the ASDK components on all task server. 

It's 4 msi files you can find in ..\Altiris\Symantec Installation Manager\Installs\Altiris\

Find the files with <asdk> <com> <altirisversion> <x64/x86>, on a 7.1 SP2 machine and installing on a x64 Site Server you would need the following.

symantec_asdk_ds_com_7_1_sp2_x64.msi

symantec_asdk_ns_com_7_1_sp2_x64.msi

symantec_asdk_swdfull_com_7_1_sp2_x64.msi

symantec_asdk_task_com_7_1_sp2_x64.msi

Thats about all the prerquisites you need to get started.

I found a way to prevent policies running during deployment task.

Set a registry key during os installation or inside your image and use an applicability rule for the policies to ask if the key exist.

If it exists policies don't run.

The point is to convert also your sub-agent policies from legacy to managed to get the benefit of a managed policy.

At the end of the deployment task just delete the key or turn it to a different value eg. ACTIVE to FINISH.

The Software Management Solution Agent Policy stays legacy as it is and will not disturb the job. At least in 7.1 SP2 (+MP1)

This way a client can be installed with a deployment job and a lot of run scripts or quick delivery task.

What do you mean by "convert sub-agent policies from legacy to managed"?

Today I went to add applicability rules to the Software Update Plug-In install policy and the Software Management Solution Plug-in install policy however neither package have an option to define applicabilty rules.

I suspect because of this conversion process you mention, can you enlighten me a little bit? 

That's a very creative idea that is actually more reliable than filters, because you don't have to wait for filters to update.  Well done!

Take note everyone.  Once the policies are configured, you never have to change them again.  Just the image / system has to be changed.  This is really good!

I'm curious, did it stop agent upgrades?  Those are built-in policies that can also interfere...

Point is either way needs quite some amount of rework if you are already far ahead in implementing.

I think with legacy to manage he essential means to recreate the agent and plugin installations as managed software deliveries. After all the packages are on the system and command lines are not that hard to find.

The update of the filters are not that much of a problem in most cases as imaging or scripted installation take a while. If you use the Global Exclude filter in the targets(instead of excluding it in filters) for software and agents/plugins policies, it should for sure be enough as the policy and target update usually runs more frequent then the delta update. Depending on your environments schedules, it could come to timing problems so.

As for agents and plugins, all plugin installations that restart the agent are disturbing the installation of a system. Tasks that run during that time will error out with "Stopped by User". Usually we install all needed plugins during firstboot with setupcomplete batch. But pcanywhere for example wont install during that stage of a win7 installation so you need to exlude systems in the installation policy if you want to keep it one for other systems for example.

@Thomas

If your agents are up-to-date in your image, no upgrade will happen. Otherwise... (see next)

@wenhamp

I only active the build-in (legacy) policies for upgrades of existing clients. Install policies have to be build completely new as managed software delivery policies. You can edit the software resources if you double-click their sw releases. If they don't appear there, enter via all resources view.

From time to time an update will come thru SIM. In this case you just have to add the applicability rule to the new agents sw resource and change it in it's installation policy.

@SashaH

As Thomas said, you dont have to fiddle around with filters and schedules. That's why we dropped the "Global Exclude" idea and thought of something new. Things can always be done better :)

I love all the comments and please keep them coming.  I really like the filter idea compared to software applicability rules.  The only reason I say this is because of the fact that I really do not want any policies running and the only way to do that is with a filter.  So here is something else I thought of:

1. Put a file in my deployment (sources\$OEM$\$1)

2, first task of the job after SOI run a gather inventory (file detail) task that only searches for this one file.

3. Write a sql filter that would look in the file details table for this entry.  If found the machine would show up in a filter.

4. Second task of the job after SOI run a Update Filter Membership task.

5.  At the end of the job delete the file.

6. Run the inventory task again

7. Run the Update Filter Membership task again

SaschaH

with setupcomplete batch. But pcanywhere for example wont install during that stage of a win7 installation

FYI - I wanted to let you know that with the setupcomplete.cmd it calls the altirisAgent.bat file.  Here I have inserted to run a batch I created agent.bat.  During this I install all the cms plug-ins including PCAnywhere as the last plug-in.  This has worked for me.

 @jlawson

Which means you put all your agent plugins into $oem$?

We also dropped that way, because an agent update would cause changes in the resource.

Update Filter Membership - how many filters do yo want to update, one for each policy?

How to avoid inventory tasks running before a client enters the filters? How about to pm agent tools and scans? They arrive really quick...

All other plugins installed well but pcanywhere never made it. which command line did you use?

Guys - there's something else you can try that didn't make it out to the world due to a misunderstanding ... somewhere.  Be that as it may, It should work... but has only been tested in one location several months ago.  Sorry - it's all I have, but if any/all of you would be willing to try, it might be useful.

In a roll-up prior to SP2 MP1 (so you'd have to be on MP1 or later to try this) they added a registry key to the NS that would tell the task server that IF a client shuts down clean and a task is forcibly stopped because of it - try that task again when the agent re-connects.

I know it's not perfect, for we'd prefer for the agent NOT to shut down during a running task.  But for the one customer that got it, it seemed to make a significant difference.

HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Pointfixes\TM PF2408200\Enable

Value of 1, set on the SMP only (not needed on site servers or clients)

Unfortunately, I have no way to confirm that this will work at this time but it's supposed to still be in the code branch.  Since it was essentially a one-off fix (it did make it into the code) it was never tested beyond the one customer.

Let me know what you find.  I hope it's a more simple method.

SaschaH please look at the solution I updated in this thread for this answer: https://www-secure.symantec.com/connect/forums/deploy-all-cms-plug-agents

@Thomas Baird -

What if the key you mentioned does not exist?

We have an SMP 7.1 SP2 MP1 environment - and that key does not exist.

Is there a hotfix we should run or should we just create the key manually?

I agree this key does not exist in my environment either:

HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Pointfixes\TM PF2408200

Unless I'm reading it wrong Thomas is instructing you to create that registry key and value on your NS.  It likely doesn't exist out of the box.

According to the eTrack for PF2408200, there should be a pf2408200_installed.reg file included in the 7.1.2 MP1.1 v3RU package; however, I cannot find it.

Adding the key seems to have no effect - either corrective or adverse.