Client Management Suite

We have Altiris NS 7.1 installed. A few days ago our server went haywire and now we have major issues with our task management server not working. Initially the Altiris Client Tasks Data Loader service failed to start but had to make some modifications to .Net Framework machine.config to get started.

It is now started but tasks are not working, sometimes it will do the first task in a job but it seems as if the agent is not reporting back which prevents any additional tasks form being carried out.

Also, when we do a NETSTA-an we see that the server is unable to bind on port: 50120 but can bind on the other 4. We have tried reinstalling the Tasks management service but no luck.. :(

The Task Management Log has the following error:

<entry process="AeXNSAgent" source="unk" time="02/08/2012 08:58:16" type="Error" >
  <![CDATA[Unable to update C:\Program Files\Altiris\TaskManagement\Altiris.ClientTask.Remoting.config: System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Program Files\Altiris\TaskManagement\Altiris.ClientTask.Remoting.config'.
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize)
   at System.Xml.XmlDownloadManager.GetStream(Uri uri, ICredentials credentials)
   at System.Xml.XmlUrlResolver.GetEntity(Uri absoluteUri, String role, Type ofObjectToReturn)
   at System.Xml.XmlTextReaderImpl.OpenUrlDelegate(Object xmlResolver)
   at System.Threading.CompressedStack.runTryCode(Object userData)
   at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
   at System.Threading.CompressedStack.Run(CompressedStack compressedStack, ContextCallback callback, Object state)
   at System.Xml.XmlTextReaderImpl.OpenUrl()
   at System.Xml.XmlTextReaderImpl.Read()
   at System.Xml.XmlLoader.Load(XmlDocument doc, XmlReader reader, Boolean preserveWhitespace)
   at System.Xml.XmlDocument.Load(XmlReader reader)
   at System.Xml.XmlDocument.Load(String filename)
   at Altiris.DotNetLib.Configuration.BaseXmlConfigurationObject.Load(String ConfigFilePath)
   at Altiris.ClientTask.Server.CTAgentInterop.UpdateRemotingConfig(TaskServiceConfiguration config, String installDir, Boolean& restartAtrsHost, Boolean& restartWWW, Boolean& restartDataLoader)]]>
 </entry>
 <entry process="AeXNSAgent" source="unk" time="02/08/2012 08:58:16" type="Info" >
  <![CDATA[CTAgentInterop::UpdateServerWebConfig(): Processing settings in D:\Program Files\Altiris\Altiris Agent\Client Task Server\ServerWeb\Altiris.ClientTask.Server.Web.config]]>
 </entry>
 <entry process="AeXNSAgent" source="unk" time="02/08/2012 08:58:16" type="Info" >
  <![CDATA[CTAgentInterop::UpdateServerWebConfig(): no changes]]>
 </entry>
 <entry process="AeXNSAgent" source="unk" time="02/08/2012 08:58:16" type="Info" >
  <![CDATA[Last known resource GUID: de65228c-f4ef-481f-85cf-7db8ac456a00; actual resource GUID: de65228c-f4ef-481f-85cf-7db8ac456a00]]>
 </entry>
 

Does anyone have any ideas?

Is it possible to build a new Altiris server and them import the existing database into that?

or you can specify the existing db as part of the NS install.

There's a handful of settings not in the db, if you look in the 7.0-7.1 migration guide that should give you an idea what they are.

The key problem from what I see (and I've seen the same thing!) is this:

 <![CDATA[Unable to update C:\Program Files\Altiris\TaskManagement\Altiris.ClientTask.Remoting.config: System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Program Files\Altiris\TaskManagement\Altiris.ClientTask.Remoting.config'.

Seems that the task Agent thinks that the Task Server is installed in a different location than it really is.  I think when I ran into this issue (maybe after applying one of the the 7.1 SP2 rollup updates?) the solution was to uninstall the Agent from the Task Server (and scrub IIS and the registry for HKLM\Software\Altiris), delete the computer in the NS, then repush the agent and reregister it as a Site Server with Task Services.

Not clear from your post if the Task Server is running on the SMP server, or you have a secondary box serving tasks; if the Task Server is ONLY on the NS, then do NOT delete the NS's record from the console, just uninstall (using aexagentutil.exe /clean /uninstallagents) and reinstall the agent manually using AeXNSC.exe.

Hallo snipesnab

I believe KSchroeder is correct on this one, i have seen similar problem, and what i found of investigating this problem was the following.

1. This file it could not find, was in fact there, this got verified by using explorer to see if it was there, and it was, this was a bit pusling, because it states that it's not there.

2. fired up procmon.exe from sysinternals (http://live.sysinternals.com/procmon.exe) to see what really was going on, and using procmon i was able to see that it tries to locate a string value within registry which was the path down to this file, which told me "name not found", i then afterwards logged onto one of our other site servers, which where working perfectly and found the registry hive in question, this one was not entirely the same.
i took the hive from the working server, and imported it, after importing it, and rebooting, the server was yet again fully operational.

What KS wrote, most likely will also solve your problem.

/Morten

Thanks very much for you help chaps...

After sending amny logs to Symantec support and lots of heard ache with production desktops sudfdenly being rebuilt as the task queue was released as it started working it boiled down to the followjng issue:

For some unknown reason the NS application stooped being able to query the CRL so timed out after 15 seconds and this caused the Data loader service to fail as well as slowing down the amdin console to a snail pace.

We did find a support article on how to fix it but we were putting the fix in the wrong place in the .Net machine.config xml file which was causing other issues.

The support engineer then rectified the config file and all is working again and the console is alot quicker.

 I would suggest that Symanted update their fix support page to be more specific about how exactly to edit the config file as not to cause issues.

The following code is required to be added:

<configuration>
   <runtime>
      <generatePublisherEvidence enabled="false"/>
   </runtime>
</configuration>

Many thanks,

Hi snipesnab

Good thing you got it working, and yer, it would prolly be a good thing for symantec to get their article updated.

Kind Regards
Morten Leth

Hi all,

I found both the Post above and the original symantec article.

I attempted to enter the information above to the machine.config file. I originally made the mistake of pasting this at the end of the config file. It caused issues for the operation of the server and I had to log in as a local admin to delete the file as elevated privilidges with domain accounts was not working.

I had taken a copy of the file as a backup prior to making any changes.

I then thought about what I was doing and found the correct method to enter the information above.

Search the machine.config file for <runtime/>. This is the empty runtime element. You will be replacing the empty element with the populated runtime element above.

Ensure to take a backup copy of the file before making any changes to the original file.

So once you have searched for and found the runtime element highlight

<runtime/>

and replace it with

<runtime>
      <generatePublisherEvidence enabled="false"/>
 </runtime>

Do not change any other elements in the config file.

Save the machine.config file. I noticed the results immeadiately.

Our server is a Windows Server 2008 x64 site server with the Task Server service installed.

Regards,

John.