The Start Software Update Cycle UI option on the client only works with policies that are set to use the global install schedule (set on the Default Software Update Agent Configuration policy).  If you set a custom schedule to install the updates at a specific time, that UI option is disabled.

Optionally, you could set your global install schedule to install updates at a specific time in the future and then the UI option should be available. 

I'm no expert on Package Servers but I believe that in  order to move all packages to a different drive, you would have to uninstall and reinstall the altiris agent to that drive.  There are options available to download the packages to an alternate location on the Package Server, however, that setting would only apply to newly created packages and wouldn't retro-actively go pack through existing packages and  change them as well.  This would results in your packages now being located on two different drives...

Hi Andrew,

thanks for your resonse.

I changed the default software update agent configuration to have a schedule of 3:00 AM every 1 days, starting 01 January 2020. This hasn't however allowed me to click on the Start Software Update Cycle. Is there anything that I am missing still?

Thanks,

Ben

By setting the global policy to - 3:00 AM every 1 days, starting 01 January 2020, means the patches will never deploy on a policy schedule (until 2020). You will always have to choose an alternate time when creating software update tasks.

What you can do is change the default policy schedule to run at an hour, and then repeat every 30 minutes or some other schedule that works for you. You can of course, chose to set custom schedules for every task.

In Patch 6.x we had several customers that only wanted to install updates "on demand."  What we had them setup was a single global policy to install updates in the year 2050.  Then, they would use the AeXPatchUtil.exe utility to install the updates "on demand."  I believe BenBrazil wants to accomplish the same thing but instead of using the command line utility, he wants to use the UI option.  I assumed that everything would work the same but maybe I'm mistaken.  I'm currently setting this up right now to see if the UI option works with a schedule that occurs in the future - again, I know the command line utility does, I just need to test the UI option... 

OK, setup the scenario here and I am able to click on the Start Software Update Cycle link to install scheduled updates.  You will notice that my "default" schedule is set to 1/1/2020.

Hi Andrew,

thanks for your testing. I'm not sure that I have explained my desired scenario that well.
What I am trying to achieve is the following:

I have a set of 11 Patch Tasks containing all of the MS Patches. I have assigned a collection called Collection1 to these Patch Tasks and in that collection I have Server1, Server2 and Server3. The Patch Tasks are all using the "Initiate execution (other than agent default) On Schedule: At 02:00 on the third Sat of every month starting Thu Nov 12 2009" therefore ignoring the default software update agent configuration and using a custom schedule.

I always want all servers in the Collection1 collection to adhere to the schedule of 02:00 on the third Sat of every month starting Thu Nov 12 2009. However I would like to have the ability to log onto any of the servers in Collection1 and initiate the update manually from the agent GUI.

In your scenario it looks like you are using the default software update agent configuration schedule for patch MS09-065. I guess the question here is whether it is possible to manually initiate a software update cycle on a client where that client has a custom schedule assigned to it.

Many thanks for all your help,

Ben

Ben,
Try running "C:\Program Files\Altiris\Altiris Agent\Agents\PatchMgmtAgentAeXPatchUtil.exe" /Xa /q as referenced above by Andrew and/or Jim. 

I would say from your result that the UI option is disabled when all assigned tasks are set to run on a specific schedule.  I would also suggest re-examining the way you are scheduling the patches.  You would probably be better off cloning the Default Software Update Agent configuration policy, modifying it to your desired schedule, and applying that towards your "Collection1" collection.  Assuming you have multiple patch cycles to address (maybe a test cycle on the 2nd Saturday of the month), clone the default policy again, apply it to the "Collection2" collection which contains server4, 5, and 6.   Then change your existing Tasks to use the default schedule and apply them to Collection3, which is comprised of Collection1 and Collection2.  This way you create a single task and it runs the patches on the schedules you've defined.

Thanks Kyle.

So are you suggesting that a clone of the Default software update agent configuration acts differently to a custom schedule is as much that it will allow you to start the software update cycle immediately?

If you can clone the default software update agent configuration what therefore becomes the default configuration when using a default schedule for the patches, ie not a custom schedule? I would assume there cant be multiple defaults.

I am as you say patching three different server groups - Dev, Test and Prod servers at different schedules. At the moment I have three different groups of patches for each environment each with custom schedules associated with them. If I were to have one set of patch tasks and change the schedule and collections on those patch tasks, I would have to edit the tasks each week to accommodate Dev, Test and Prod patch days. This could potentially allow for using a default schedule, however would require more administrative weekly effort. Is there any other way around this?

Thanks,

Ben

To answer your question directly, No, in the current product you cannot manually initiate the installation of updates that are configured with a custom schedule.  Kyle has a good idea though - simply clone the "default" global policy and set different schedules according to your needs... 

Ben,
From what I know, the whole idea is that you clone the "Default" Software Update Agent (SUA) policy and apply each clone copy to a different collection (which you need to take care that there isn't overlap between, which if you have Dev, Test, and Prod should be fairly straight-forward).  This is how our server team patches our servers (though they have about 50 different policies configured as we have a Test/Dev, Prod1 and Prod2 group, and within each of those 6-8 policies based on the Time Zone the server is in since we patch on local time at HQ, regardless of the timezone the server itself is in.  All of our complaining finally got "Using the NS Time" scheduling added in Patch 7, Thanks Andrew!).

So you could have 3 different policies (and the original "default" which automatically applies to any computer which doesn't have another policy defined) defined, one for each server collection: Dev, Test, Prod.  Each month you create your Patch task on the week of Dev patching and apply it to the Dev collection.  On the 2nd Saturday (or whatever the schedule is configured on the Policy, not the Software Update Task) the patches will install on the Dev servers.  Then on the day before the Test servers patching schedule, you add the Test collection to the same task (no need to create a new task) and on the scheduled day of Test patching, the patches install.  Then you add the Prod collection (again to the same existing Task) on the 3rd Friday and on the next day the Prod servers get patched.

Optionally, you then you create a 4th collection "All Servers for Patching" which is created by explicit inclusions of the Dev, Test, and Prod collections.  When you create the  Software Update Task you apply it to the "All Servers for Patching" collection.  All the servers will be targeted for patching (and will download the patch packages/binaries in advance), but they won't actually run until their scheduled install day (defined in the Software Update Agent policy).  This is easier and will let the Dev boxes go on the 2nd Saturday, Test on the scheduled day, and Prod on the 3rd Saturday. 

This way is actually much LESS overhead as all you have to do is create new tasks each month.  Any new servers will get the new patches and any old ones they still need, still on their schedule.  Even beyond that, you could apply the patches to "All Windows Servers".  Any that aren't explicitly in the Dev, Test, or Prod collections will use the actual "default" schedule that you've set to run on 12/31/2050 or whatever.  This will allow you to login to those servers and click the "Start Software Update Cycle" link in the User Interface to patch manually.  This might be good for those "special" servers that need services/applications shut down before patching.

One final "gotcha" is that you may, depending on how the days of the month fall, need to modify the SUA Policies to make sure the patches run when you want.  Consider next month (December 2009) for example.  The 3rd Saturday of the month will be December 16, but Patch Tuesday will actually occur only 4 days earlier on Dec 12.  So in this case you'll want to bump the schedule to the 4th/last Saturday to avoid patching only 4 days after the patches are released.

Kyle,

thanks for taking the time to write your last response.
I have cloned the Default Software Update Agent Configuration Policy and have applied it to a collection called Unpatched. I have called the new policy Unpatched Default Software Update Agent Configuration Policy.

I haven't changed my Software Update Tasks yet. I still have a Dev, Test, Prod and Unpatched set of tasks. My Unpatched Software Update Tasks are applied to the Unpatched collection. Under package options I have left the "Initiate execution (other than agent default) unticked. What I am unclear of still is if there are multiple default policies, how does this Software Update Task know what policy to use? Does linking a Software Update Agent Configuration Policy to collection and then linking Software Update Task to a collection imply that the Software Update Task will receive that policy?

Thanks,

Ben

Thanks for all your replies.

I think I am gonig to leave my Patching structure as it is, but change the Unpatched tasks to the Default update policy to install every night. That way I can either leave new server to patch automatically or manually go on the server and initiate a patch straight away.

Regards,

Ben