Login to participate
Endpoint Management & Virtualization ArticlesRSS

Creating a Scheduled Installation

Harsh's picture

Normally when you install an application you double-click the MSI or pass it through a command line (when it is part of a local or manual installation). For example, when you double-click, it gets passed through a command line and uses administrative privileges to install application.

But have you ever tried a system context Installation? i.e scheduling an installation that takes place at the system level with system privileges.

What Makes This Type of Installation Useful?

These types of installations kind of simulate installations using a deployment tool.

In simple terms you can schedule the installation and it will take place with or without user interaction -- even if the user is logged on without administrative privileges.

This definately saves testing time in terms of uploading packages to a deployment tool and then firing the query to test whether it works with a deployment tool or not.

As per my experience, if an application installs and works AT command, then it always gets installed and works with any deployment tool.

Try it out. I'm sure you won't be dissappointed.

When you install using AT command, the application is self healed in administrator also. As user data (HKCU registries and User profile file) do not get install. The installation is with privileges of system and not with administration. It treats Administrator as user and does not install user data. When you launch first time, it will self repair and does install user data.

Brief About AT command

You can use the "at" command to schedule a
-> command
-> installation
-> a script
-> a program
to run at a specified date and time.

You can also use this command to view existing scheduled tasks.

The AT command schedules commands and programs to run on a computer at a specified time and date. The Schedule service must be running to use the AT command.

To use the AT command, the Task Scheduler service must be running, and you must be logged on as a member of the local Administrators group. When you use the AT command to create tasks, you must configure the tasks so that they run in the same user account.

Once you complete your command and schedule your task on local machine you can log off.

The task will execute at the time it was scheduled.

System Context Installation Using AT command

The AT command uses the following syntax:

To schedule task:

at \\computername time /interactive | /every:date,... /next:date,... command

To delete scheduled task:

at \\computername id /delete | /delete/yes

More command information can be find by typing:

at /?

Here's how we can install application using AT command.

The recommended method ->
Create one batch file which have MSI Installation command. Example ->

Install.bat file contains:
MSIEXEC /I "C:\Install_apps\office.MSI" /qb

Then on command prompt:

Type command in following format:
At <time> <mode> <command>

Example:
At 21:00 /interactive "c:\install.bat"

Then you can see:

To view status use following command:

Hence, today at 21:00 the command install.bat will get execute. That means the application Office will get installed on this system at 21:00.

This is the way we can schedule the application installation without a deployment tool.

riva11's picture

AT command

Thanks for your post, I used AT command in the past and can be a valid alternative way.

Scott Jones's picture

AT Command and SVS Layers

The AT command is also an important tip for techs working with SVS layers!

Since SVS layers carry the ACL's from the machine where the layer was created, sometimes you may find yourself with stuff in a layer that you can't edit or delete locally on the client you're sitting at. For example, the content of someone else's user profile (which, of course, would actually be an issue even without SVS -- but often we find ourselves wanting to clean up SVS layers by deleting unneeded user-specific data). Or more specifically to SVS -- and this one can be confusing the first time you encounter it -- when the packager was logged in to their machine with elevated privileges, but not using a well-known SID account like "Administrator".

If you find yourself needing to edit layer content but don't appear to have enough rights, you can either muck with the permissions settings (probably having to re-assign ownership of the objects first, then change the permissions, then make whatever edits you want)... which of course permanently changes the local copy of that layer, so then, theoretically, you should put it back the way it was when you're done... Or you can just crank up Explorer and/or Regedit using the AT command!

For example:

at 00:00 /interactive regedit

...where "00:00" is one minute in the future.

Then you can do whatever you need to, fairly quickly, without altering the security settings on the layer content.

Tada!

Scott Jones
Product Manager
Altiris, Inc.
Now Part of Symantec