In this article, we'll look at what we can do to help manage computers once they're in the console. We'll cover the basics here, such as inventory and remote control, before proceeding to create our first task which will be to reboot a computer.
Computer Inventory
Let's now return to the server with out XP computer in the console -you'll find it under the "All Computers" group as shown in Figure 15. If you are following these notes on my course, the computer loaded with the AClient is called XP-Client. If we select the computer in the computers pane, we can see from the details pane a status entry. This informs us that inventory has been received.
Figure 15: Console screenshot showing the newly managed computer called 'XP-Client'. We can see from the information here that it is an XP computer, with the administrator is currently logged in. The IP,MAC Address and processor architecture are also shown.
Note also the icon representing the computer -it shows a desktop with a user beside it. This icon reflects that a user is currently logged into the computer. If you look at the header of the details pane, you'll see immediately that the user logged in is XP-Client\Administrator -very useful.
The details pane also shows some useful inventory items such as the processor architecture, IP address and MAC address. To view all the inventory information, just double-click the computer to bring up the "Computer Properties" window. Here you can find,
- Hardware Information -such as Processor type, memory, computer model, serial number & BIOS revision
- Fixed Disk information -including capacity, free space and filesystem type
- Microsoft/Netware networking information
- TCP/IP information -including network card vendor and model revision
- Add/Remove program data
- System Services data
- Device Manager summary
To illustrate the depth of information which the agent inventories, below I show in a hardware screengrab from the 'Computer Properties' page,
Figure 16: An example of the hardware information gleaned from the agent inventory as presented from the 'Computer Properties' page
Computer Groups
Before we dive into the interesting bit of creating jobs to run on our newly imported computer, let's do some tidying up. Our newly managed XP laptop currently resides in the root of the "All Computers" folder.
Its good practice to file away any computers that appear here into a sensible hierarchy.
Let's create a computer group hierarchy, assuming that this laptop belongs to someone in human resources,
- In the computers pane, right-click "All Computers" and select "New Group" from the Context menu. Name the new group "Staff Machines"
- Right-click the "Staff Machines" group, and create a new group called "Accounts"
- Right-click the "Staff Machines" group, and create a new group called "Personnel"
- Select the computer you imported, and drag it into the "Personnel" group
Get into the habit of moving computers into logical groups as they appear in DS. Its not all manual work though -in large rollouts we can create custom input files which place your computers into specific groups.
Jobs: Creating a Power Control Task
Creating and deploying jobs is life's blood of DS. In Deployment Server terminology, a Job is a collection of one of more tasks, and there are many types of tasks that DS is configured to handle,
- OS Deployment Tasks
- Create Disk Image
- Distribute Disk Image
- Scripted OS Install
- Package Deployment Tasks
- Distribute Software
- Manage SVS (Software Virtualisation Solution) Layer
- Capture Personality
- Distribute Personality
- Registry Tasks
- Backup Registry
- Restore Registry
- Miscellaneous
- Modify Configuration
- Get Inventory
- Run Script
- Copy File to
- Power Control
- Wait
Pretty daunting! So let's start by creating a simple job consisting of one task. One job which might be useful to have on DS is one which reboots a computer; let's call it "Helpdesk Reboot".
Helpdesk Reboot and Agent Prompts
A reboot job is pretty simple to create in DS,
- Right-click in the jobs pane, and select "New Folder" to create a folder called "Helpdesk Tasks" (this is just to keep our jobs tidy!)
- Right-Click the "Helpdesk Tasks" folder and select "New Job" from the context menu. Call the new job "Helpdesk Reboot"
- In the details pane, add a "Power Control" task to the "Helpdesk Reboot" job. Select "Restart" from the options.
As we generally don't want a system reboot to be held up by open files, let's tick the checkbox to force applications to close without a message. This may appear mean, but if you really want to ensure a reboot occurs, this is critical.
- Click "Next" to move on to the "Return Codes" form
This form allows us to perform specific actions based on the program's return code, that is the error flag each program sets on completion to let us know how well it did. We don't need to think about return codes just yet, so click "Finish"
So, that's our Reboot job created, now let's execute it on the computer.
- Drag the computer on to the "Helpdesk Reboot" job (or vice-versa) to begin scheduling the job,
When you've dropped a job on your target computer, the Deployment Console will offer you the chance to schedule the job. By default, the scheduling is set to "Run this Job Immediately", but you also have the option of setting this for a later time. As a safety precaution, the tabs on this dialog offer you the chance to review the job(s) and computer(s) which have been associated.
Stick with the default to run the job immediately, and click OK. After one final confirmation, sit back and watch your client reboot.
If you recall, when we configured our AClient configuration file we set an entry to force reboots requests to be prompted,
It should not come as a huge surprise then when on your Windows XP client, you now see an Altiris Client Service Message window, informing you that a power control task has been scheduled to run. This is because we pre-configured this warning in the input file. Unless you defer the reboot, or abort the job, your computer will reboot in 10 seconds (these being the default timeout and action).
On top of providing a humble example of a Deployment Server job, this reboot job illustrates the power you give to your users should you make the AClient visible. In short, with a visible client, you users are capable of configuring their User Properties so that they can abort job deployments on their computers.
Remote Control
If you right-click your computer in the console, you'll have two Remote options available,
- Remote Control
This is the Deployment Server's own remote option. This allows you to remote in and share someone else's desktop to troubleshoot issues. It provides instant access -no authentication, and no auditing (with the exception of the log files)
- Remote Desktop
This is a quick link to fire up the Microsoft RDP Client. This does not share the remote machines desktop, and you are required to login. Remember though that this will not work out of the box -you'll need to enable remote desktop on the PC via the remote options in the computer's system properties.
If you recall, when we installed the agent we specified in the input file to allow remote control. Try this out now.
- Right-click you XP Client computer, and select "Remote Control" from the options in the context menu.
- After a moment where it attempts to connect with the message "waiting for clients to accept connection", you should be presented with your client's screen,
There are a couple of items on the menu bar which are worthy of mention,
- Chat
You can initiate a chat session whilst doing remote control -most useful.
- File Copy
This copies files to the client computer. To speed things up on slow connections, compression can be enabled and they can even be encrypted.
- CTRL+ALT+Delete
This primarily allows us to login to machines where the GINA is present and requesting our CTRL-ALT-DELETE signal to get the login prompt
- Toggle Control
Allows you to toggle whether your keyboard and mouse movements in the Remote Control windows are transferred the target computer or not. On the control menu bar you can also disable client input entirely.
The Remote Red Eye
A comforting feature of remote control for users is that during a remote session, the AClient flashes showing a red eye. When the remote control session ends, the AClient icon once again returns to the traditional AClient icon. This is a great indicator for users that their desktop is being shared, and this behaviour cannot be turned off. Note the remote red eye feature is not available through the DAgent.
Chat
Another helpdesk tool which is available from the computer context menu is the "Chat" program. Its a shame it can't be customised to look more friendly to users in your environment -users are generally quite bewildered when they first see it.
Above I show a sceptical user's response to a chat session. In most scenarios you're lucky if you get his far -on being presented with an unknown window popup the instant response of most users is to close it. To get around this, compose your message in notepad first, copying it to the buffer, then initiate chat pasting your message instantly and sending. This should give the user something to read instantly -perhaps belaying the impulse close the window.
Return to Index
Read Part 11: Deployment Server 6.9 - A Quick-Start Course, Part 11: Imaging with PXE