Deployment Console: Why are the Computers Offline? ~ Troubleshooting ~
I am sure many of you whom use DS 6.X experience times where there are computers that are on the network, but are not showing up online within the Deployment Console. The following will explain how to fix this and avoid it from happening in the future.
Part 1: Getting computers to show up in the Deployment Console as "Online" again.
It is frustrating, I know, to have tens or hundreds of machines not showing up in the console as online when you know for sure that they are on the network. This usually occurs when the agent itself stops reporting to the server on the client machine. When the client is not reporting, there are two ways to fix this;
Technique 1: Restarting the service on the machine
In order to do this, you will need to have administrative rights on the local machine (normally is not a problem). To restart the service, bring up your services.msc by clicking on Start > Run > Type in "Services.msc" (without the quotes) and press enter. In the top left of the services screen, you will need to right click on "Services (Local)" and then "Connect to Another Computer".

Type in the computers name, or use the browse button to select the computer from a list in order to manage services on and click OK.

Once the target machine has been selected, stop the Altiris Deployment Service, and then start it up again.

This should get the computer talking to the Deployment Console again. Although this solution will work, this is not a good approach for multiple machines all having the same issue.
Technique 2: Using Remote Agent Installer to Over Install
The Altiris Deployment Console has a built in feature to install the Deployment Agent on remote machines. Using this can reinstall the client on the machine thus hopefully fixing the problem. To use this feature, click on the antenna icon within the Deployment Console.

Enter your credentials (needs local administrator rights to the machines to be run on)and then click Next. In the next screen, review your Install Directory path, and "Agent Settings Summary" and be sure that the IP and settings match your standards.

Click, Next, and choose whether to add the machines to the default group or to a specific group and then click next again once done.

In the next screen, you will need to click on the "Add" button and then browse computers for either the OU you want to select, or individual machines or every computer in your entire AD environment if you would like to reinstall the agent on. You can hold the Shift button on your keyboard and click "A" to select all or hold Control and click individual machines to add them incrementally to your list.

Once you have compiled your list of machines, click OK. Click on "Finish" once you are satisfied with the machines to have the agent reinstalled on and it will do the rest and show the results once finished.

Technique 3: Running a VB Script to Restart the Altiris Service
For those of you whom happen to be scripting friendly, I have a home grown script to restart services on machines based upon the Active Directory OU you choose to run it on. Little modification is needed, and you can copy / paste this into a text file and save this as a .VBS and run it in your environment once you change the OU name on it. Be sure to run this script as an administrator of the machines in the selected OU otherwise it will not work of course!
' Benjamin Fuller
' Script to Restart the DAgent on local machines
' Change YOUR_COMPUTERS_OU on the PCQuery line in order for it to work on your OU
On Error Resume Next
Dim PCQuery, objConnection, objCommand, objRecordSetDim oRootDSE, strDNC
'First get domain information
Set oRootDSE = GetObject("LDAP://rootDSE")
strDNC = oRootDSE.get("defaultNamingContext")
' other categories = computer, user, group
PCQuery = "<LDAP://CN=YOUR_COMPUTERS_OU" & strDNC & _
">;(objectCategory=computer)" & _
";distinguishedName,name;subtree"
Set objConnection = CreateObject("ADODB.Connection")
Set objCommand = CreateObject("ADODB.Command")
objConnection.Open "Provider=ADsDSOObject;"
objCommand.ActiveConnection = objConnection
objCommand.CommandText = PCQuery
Set objRecordSet = objCommand.Execute
Do Until objRecordSet.EOF
'assign the computer name and distinguished path to variables
strComputer = objRecordSet.Fields("name")
strComputerDN = objRecordSet.Fields("distinguishedName")
On Error Resume Next
'open the file system object
Set oFSO = CreateObject("Scripting.FileSystemObject")
set WSHShell = wscript.createObject("wscript.shell")
'open the data fileSet oTextStream = oFSO.OpenTextFile("wslist.txt")
'make an array from the data file
RemotePC = Split(oTextStream.ReadAll, vbNewLine)
'close the data file
oTextStream.CloseFor Each strComputer In RemotePC
strServiceName = "Altiris Deployment Agent"
Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")
Set colListOfServices = objWMIService.ExecQuery("Select * from Win32_Service Where Name ='" &
strServiceName & "'")
For Each objService in colListOfServices
objService.StopService()
Next
strServiceName = "Altiris Deployment Agent"
Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")
Set colListOfServices = objWMIService.ExecQuery ("Select * from Win32_Service Where Name ='" &
strServiceName & "'")
For Each objService in colListOfServices
objService.StartService()
Next
Next
objrecordset.MoveNext
Loop
objConnection.Close
That should sum up all that you will need to get the computers checking in again. The next part will help prevent it from happening in the first place!
Part 2: Preventing "Offline" Machines While they are Clearly Connected to the Network!
I may have this problem more than others, most of the machines in my network are laptops and roam from conference room to their desks and back. This causes them to go from the LAN, the the WLAN and back again multiple times a day. It seems that during the process of doing so, the client somehow stops reporting to the server. By default, most machines will check in to the Deployment Console during startup, logging on, and every four hours incremental regardless. Considering that every four hours it will check in, that could mean if a user goes to a conference room in the morning, their machine may not check back in until sometime after lunch break!
I have changed the Production Agent settings on all of my machines within the Deployment Console to check in on a regular interval of one hour. This way, 95% of the machines in the console will always be checked in and online if they are physically here and on the network. In order to do so, within your Deployment Console, click on "All Computers" and then select all machines by holding down the Control button on the keyboard and pressing A. Once all of the machines are selected, right click on one of them and click on "Change Agent Settings" > "Production Agent".

Once you bring up the Production Agent Settings box, you will want to change "Refresh Connection After Idle" hours to 1 (or to your preference).

After changing this field, click OK and then your machines will update to these settings the next time they check into the Deployment Console. After they check in and take these settings, every hour (If you chose one hour) the machine will check back in rather than every four. This leaves less room for error!
Let me know if this helped you, feedback is always appreciated!
Comments
Good article. I have run
Good article. I have run into this situation more times than I care to count and can quote some really bizarre answers to this from Symantec Management on this issue.
I have seen these symptoms as a precursor to my DS server stopping some but not all of the Altiris related services. It took some time, but eventually, I found 2 things that will are preventative and help to keep this from happening.
1. Keep your express DB on a strict diet! If it gets over 200 MB, you will start seeing crazy stuff like what is presented here and times where jobs just don't start. Our DB likes doughnuts and a dozen of them got me a set of maintenance plans that run at 2 a.m. every day to keep thins nice and lean. After that I pruned down our history retention settings until I was consistently remaining within bounds.
2. This one is so simple, that I get alot of weird comments and then people try it ... I have a scheduled task at 3:00 a.m. everyday to run a batch file. I named the batch file reboot.bat and it contains only 1 line: C:\WINDOWS\system32\shutdown.exe /r /t 30
When we first implemented 6.9, we were "down" multiple times a day. Since I figured out these two things, it is a very long time in between failures! Usually, I just have to manually shrink the DB, reboot, and keep going.
Thanks wmheid! I have run DS
Thanks wmheid!
I have run DS 6.9 in a few different environments, some large (15000+ Machines) some small and some medium sized like where I am now with 1000 nodes connected. I have noticed better performace from smaller DB's but also had noticed that no matter how large or small there are some bugs with the client machines reporting in themselves.
I give it a 15 - 20% failure rate, and in a laptop environment like I am in now seems even worse, about 25 - 35% failure rate due to changing from LAN to WLAN multiple times a day... It doesnt seem so much a problem in my 7.1 environment - but not everybody can snap their fingers and migrate to the new version unfortunately!
You break IT, I fix IT!
Number 1 here was my problem
Number 1 here was my problem I think... we'd briefly (for a few months) had our DS 6.9 running on a 'real' SQL Server installation, and I'm guessing that it defaulted to Full Recovery instead of Bulk or Simple, which is why I just found a 32 gig DS database due to a 31.9 gig transaction log. After changing it from Bulk to Simple and shrinking it (though it claimed to only have 25 megs free space), I'm down to a 160mb database with a 120mb or so transaction log. I'm expecting significantly better results now... thanks! :)
I have also seen this problem
I have also seen this problem if your computers are going through a firewall or similar device.
What will happen is that the Firewall will drop the open connection from the computer to server if it deems to the connection to be idle.
Normally you can set the timeout on the firewall to a higher limit, as from what l remember the refresh settings on the agent cant be set very low.
This document helps us a lot.
This document helps us a lot. On DS 6.9, this happened a lot after the SP5 upgrade. Thank you very much for the script to restart the services. Much appreciated!
Glad I could help out! Works
Glad I could help out! Works like a charm for me!
You break IT, I fix IT!
Would you like to reply?
Login or Register to post your comment.