What version of Radia are you using? will the MS Patches be set to Mandatory or optional? You may want to create a local ZtimeQ on the Agent that will automatically call out to the Core server based on a timeframe you select (daily, weekly, other) The timer will use the local time on the PC/Laptop.

Other suggestion- would be to install Seft Service Manager this Applet will allow the user to invoke MS Patching when they chose and also... you can set an a date and time that it will install if the user has not invoked the install...

We use a VPN agent (Cisco Any Connect Secure Mobility Client.

I'd recommend using a TIMER based solution like the previous reply has said.

Create a new instance in SOFTWARE.ZSERVICE called LAPTOP_TIMERS.

Create two new SOFTWARE.TIMER instances, one called PATCH_DAILY and one called SOFTWARE_DAILY and attach them to SOFTWARE.ZSERVICE.LAPTOP_TIMERS.

Define each of the timers as follows:

PATCH_DAILY

ZOBJPRI 50

ZSCHDEF DAILY (&ZSYSDATE,12:00:00,14:00:00,18:00:00)

ZSCHTYPE DEFERRED

ZSCHFREQ RANDOM

ZRSCCMDL radskman dname=PATCH,ip=<your rcs ip address>,log=PATCH_DAILY.LOG,hreboot=y,ask=y

ZNOPING W

PINGDLAY 2000

PINCNT 3

NETAVAIL W

PATCH_SOFTWARE

ZOBJPRI 10

ZSCHDEF DAILY (&ZSYSDATE,09:00:00,12:00:00,18:00:00)

ZSCHTYPE DEFERRED

ZSCHFREQ RANDOM

ZRSCCMDL radskman dname=SOFTWARE,ip=<your rcs ip address>,log=SOFTWARE_DAILY.log,hreboot=y,ask=y

ZNOPING W

PINGDLAY 2000

PINCNT 3

NETAVAIL W

These definitions will mean that timers will only expire and run if they can see the HPCA/Radia infrastructure. They will also only run up until 6pm and won't attempt to run past this time.

Policy entitle SOFWARE/LAPTOP_TIMERS to your end client devices.

Your challenge is how to deploy these timers if your end clients are already remote. I'd suggest using a logon script to run an HPCA connect like this:

radntfyc localhost radskman ip=<your rcs ip address>,dname=SOFTWARE,sname=LAPTOP_TIMERS,log=LAPTOP_TIMERS.LOG,ind=n,del=n,hreboot=n,ask=n

It's also handy to put into the login script a check for the existence of the file Agent\lib\ZTIMEQ.EDM. If it doesn't exist then launch the command above.

A word of warning on VPN client management. Don't package it with an uninstall method. Otherwise if you ever want to upgrade the original package will be removed first, loosing your VPN capability before the new package is deployed.

Take a look at Connect and Reboot Defer. These are two good features to help your remote end clients.

Sorry for the delay responding. We are using Radia 9.02, as of today we are doing everything as Mandatory. we do have timers that connect daily with the random option set. we do not use the Self Service Applet because we can't rely on the users doing this themselves. We use NetMotion which creates a VPN connection to our network, we have about 2900 mobile computers and we don't want to consume all the bandwidth for patching, 50% of this units are home base reporting and occasionally might come in to the yard to get items. 

James and I actually work together so leaning on his suggestion one thing we do in our 9.02 environment to assist with bandwidth consumption is breaking the timer up a bit. We have created a solution where the environment is separated by roughly 20% per night. The time has two modes: full patch connects once per week and the rest simply perform a patch scan. This allows our systems to have much better bandwidth connections at the same time breaks up the machines so they are not doing full patch connects each night let alone all on the same nights. One thing this also fixes is the ungodly download of discover patch. Normally in a standard patch connect it is forced to download a new discover patch when it first connects no matter what. By breaking the time up like we did it will not download the Discover Patch until it is that system's full patch connect night. Additionally we set a flag at the end of that full connect night to run another full connect if the download didn't finish the previous night. We are constrained to time limitations for downloading and installing things hence the need for that last portion, but if your not you could skip it. Either way I would not use the internal bandwidth limitations of Radia as they do not work well over VPN or any other sort of connections unless it is direct to the server. I would recommend QoS on the pipeline if your wanting to throttle the connection. We have learned this from years of being a managed services provider. We have customers connecting to us with VPN/MPLS/Wireless/Over the internet basically you name it we probably have a connection in that form. The internal bandwidth throttling basically sends ICMP packets and calculates based off the MS what your bandwidth is. It is bad at factoring in additional connection types along the way so we us a vpn customer ends up getting a message in the log of "using 0 bandwidth of 0" because it cannot calculate properly and it slows the download very badly.

Let me know if you have any other questions about our setup.

Our size is roughly 25k active connections on 17 client facing servers

Service will run normal patch connect, How it will know which patch to download ? Do we need to apply any policy from Radia side also ?