Client Management Suite

 View Only

Deployment Console: Why are the Computers Offline? ~ Troubleshooting ~ 

Oct 13, 2011 01:16 PM

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!

Statistics
0 Favorited
1 Views
10 Files
0 Shares
0 Downloads
Attachment(s)
jpg file
Change_Agent.jpg   129 KB   1 version
Uploaded - Feb 25, 2020
jpg file
Prod_Agent.jpg   62 KB   1 version
Uploaded - Feb 25, 2020
jpg file
Remote_3.jpg   54 KB   1 version
Uploaded - Feb 25, 2020
jpg file
Remote_4.jpg   186 KB   1 version
Uploaded - Feb 25, 2020
jpg file
Remote_5.jpg   40 KB   1 version
Uploaded - Feb 25, 2020
jpg file
Remote_Agent_Install.jpg   123 KB   1 version
Uploaded - Feb 25, 2020
jpg file
Remote_Install_2.jpg   77 KB   1 version
Uploaded - Feb 25, 2020
jpg file
Selectcomputer.jpg   30 KB   1 version
Uploaded - Feb 25, 2020
jpg file
Services.jpg   174 KB   1 version
Uploaded - Feb 25, 2020
jpg file
Stop.jpg   155 KB   1 version
Uploaded - Feb 25, 2020

Tags and Keywords

Comments

Jan 23, 2014 12:26 PM

This may be an older post, but it's still very relevant so I would add that an alternative to the GUI or VBScript would be single a single command line statement:

sc \\computer1 start "Altiris Deployment Agent"

It accomplishes the same thing as the GUI method on a single computer, but you don't have to go though multiple steps to connect to the remote computer.

 

Jan 03, 2012 02:26 PM

Glad I could help out! Works like a charm for me!

Dec 27, 2011 01:22 PM

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!

Dec 13, 2011 05:44 PM

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! :)

Dec 06, 2011 06:17 PM

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. 

Oct 17, 2011 10:36 AM

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!

Oct 15, 2011 07:00 AM

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.

 

 

Related Entries and Links

No Related Resource entered.