Client Management Suite

<response result="failure" code="6" description="The handler 'Register.aspx' failed to process request.">

System.Exception: We cannot service this request because the web application failed to initialize. ---> System.Exception: Unable to configure remoting during Application Start ---> System.Exception: Unable to read install directory from Software\Altiris\eXpress\TaskServerSetup at Altiris.TaskManagement.Common.ClientTask.Configuration.ClientTaskServerConfiguration.get_TaskServerInstallDirectory() at Altiris.ClientTask.Server.HttpHandlers.WebClientApiManager.Initialize(String configFilePath) at Altiris.ClientTask.Server.Web.Global.Application_Start(Object sender, EventArgs e) --- End of inner exception stack trace --- --- End of inner exception stack trace --- at Altiris.ClientTask.Server.HttpHandlers.WebClientApiManager.CheckStartupException() at Altiris.ClientTask.Server.HttpHandlers.WebClientApiManager.ProcessRegister(XmlTextWriter wr, NameValueCollection queryValues, Stream requestStream, Int32 contentLength) at Altiris.ClientTask.Server.HttpHandlers.Register.WriteResponse(XmlTextWriter wr)

</response>

Hi,

Please try to add local "Users" group to the security permissions of the "Altiris Agent\Client Task Server".

This problem reported sometimes, but we were not able to understand exacts steps how to reproduce it. It is definitely related to the non-default install path. It seems like in case of install to the default "Program Files" directory local Users group added to the Client Task Server permissions as inheritance from the "Program Files" folder. And it seems like the same group is missing in case of non-default install.

Is it possible to share OS details, OS install steps, OS configuration steps before the Symantec Management Agent install? Was the Package Server installed on the same server?

Any info will be really helpful!

Thank you,

Alex.

We have tried adding everything under the sun, including local and domain "Everyone" groups with read and still no dice.

Peculiar behavior. 

Hi Alex,

Thank you for the response.  We have tried adding the Users to that folder.   We have even tried granting "Everyone" full control of that entire drive.  None of this has worked.  We get the same error message.

Here is some more information:

Installation steps:

1. Clean install of Win 2008 R2 standard with 2 volumes (C/D)
2. Set up Pre-Reqs for Task Server/Package Server as outlined in documentation (IIS with Metabase compatibility, ASP.net, etc)
3. Initial install of Symantec Mgmt Agent was on C drive, along with Task Server and Package Server
4. Removed the C drive install because we want everything on D
5. Pushed the Sym agent install from the NS console onto the D drive of remote server. 
6. Installed the Task Server on top of agent using NS console

We've tried re-installing IIS from scratch, uninstalling and re-installing the Sym agent multiple times.  But nothing is working. 

At this point, I am wondering if anyone has gotten a remote site server running off a D drive on SMP 7.5.

Hey all,

This issue is resolved.   I wanted to post what we found in case anyone else runs in the same problem.  The steps we took to install are posted above. 

Here are the steps we took

1. We gave full permissions to the user's and IIS users group to the reg key Software\Altiris\eXpress\TaskServerSetup. 
2. We also gave full permissions for IIS Users and Local Users to the logical drive hosting the task server files (as pointed out by Alex above).
3. We looked at app pool on the remote site server and changed the idle  timeout settings to match the SMP.  We made sure that the Classic .NET App pool was being used (this was already in place).  We also switched a couple of times between Network Service and AppPoolIdentity account as the identity for the app pool.  We left it at  AppPoolIdentity. 

It is now working as expected.  We believe that the combination of adding permissions to the logical drive and switching the app pool identity account between app identity and network service and then back somehow did it.

Thank you for your help, Alex.

Hi ebooda,

Many thanks for the providing detailed config information! I'm trying currently to replicate the probem ans such info really helps!

Thank again,

Alex.

Update: I have tried scenario "install SMA to the default path, install PS, uninstall SMA, install SMA to non-default path, install TS" on size 2008.R2 servers and was unable to reproduce this problem so far.

Problem is definitely exists, but it looks like something is missing in my steps or config.. Maybe the way how SMA was install and uninstalled? Which user used to install SMA and does such user has some restricted rights?

Hello,

I had very similar problem like ebooda (site server SMA installed by mistake to default location, then reinstalled to D: drive...). I tried the mentioned steps.

1. No impact

2. No impact

3. Altiris site has been configured to use DefaultAppPool. It has been switched to the Classic .NET AppPool and it works fine.

So I can recommend check the App pool first and try to switch to the Classic pool (or switch to Default and then back).

Hi shiwo,

In your case, was it clean install or upgrade from the previous version? Was the package server installed on the same site-server? How exactly Symantec Managed Agent was rolled-out to the site-server computer? Was it installed under the sustem account or you have used some specific account? How uninstall was performed?

I'm sorry for the number of questions, but if you may answer them it could help to nail down the problem. The main issue to me that I cannot reproduce this bug with given scenario (install to default, uninstall, install to non-default).

Thank you,

Alex.

P.S. Task Server issues could be logged to the Task Server group: https://www-secure.symantec.com/connect/groups/task-server-0

Hi Alex,

I'm affraid my case is too specific to reproduce :) But I can try to answer. There was SMA 7.1 on site server, with TS+PS+NBS. By mistake SMA was uninstalled, then installed in wrong (default) directory, then uninstalled and installed again in original directory. But task service and package service was corrupted so I installed them manually. Then I decided to migrate to 7.5 so I completely uninstall the site server via SMC policies and task (I can't remember if SMA was uninstalled by aexagentutil or by console command), I cleaned all the directories and registry entries. I forgot to check the IIS for some rests.

Then SMA 7.5 has been installed via SMC > Rollout Agent to Computers, with overriden installation path (same as original) and with default application credentials (dedicated domain account). Then TS+PS+NBS was installed according to the installation instructions.

How I said, it was little messy on site server. It was the reason, why I didn't report the case on Symantec support.

Hi shiwo,

Thank you again for the cooperation. As problem has reproduced already on several customers’ setups, we have to understand what is missing in our TS install checks and how we could avoid such problem. So it still should be something to fix on our end.

Two questions:

1. Was some updates (for MS .Net Framework, for example) performed between the 7.1 and 7.5 install?

2. "Dedicated domain account" - did I understood correctly, what this account is "domain user" account with local administrative rights on a site-server computer? Or this user has some specific rights?

BWT: so far I know three problems that could happen in PS&TS install-reinstall scenarios:

1. If you install PS before the TS and then uninstall PS then TS web-site install will be corrupted. To fix it you need to restart atrshost service - it should re-create TS web-folder.

2. If you uninstall TS manually and then remove IIS Altiris folder manually then next TS roll-out won't create TS web-folder, as such folder still exists in IIS cache and setup will skip its creation. Workaround: create web-folder manually and restart atrshost service.

3. If TS was installed to the location where security permissions was modified to remove access to local Users group then TS won't work and you will see warnings in agent log with "HTTP error 500 (80042D21)" when agent attempts to register to such TS.

Thank you,

Alex.

Hi Alex,

1.  Did you mean between 7.1 uninstallation and 7.5 installation? No MS updates were performed. Or did you mean between 7.1 installation and 7.5 installation? Yes, 7.1 version ran on the site server for two years, so security updates were performed.

2. Yes, domain account  with local administrator rights.

Hi shiwo,

I mean "between the 7.1 and 7.5" and mostly interested in framework upgrade - have you installed MS .Net Framework 40?

So far I cannot reproduce it, tried your steps with 4 different site-servers (different OS, different users logged-in, slightly different install-reinstall scenarios). There should be something what I’m missing..

Thank you,

Alex.

Hi Alex,

.NET Framework 4 has been installed on the machine long time ago, before Altiris SS installation. Last update of .NET Framework 4 has been installed 3 month ago, when 7.1 was running yet.

How I said it was nonstandart situation and I don't blame Symantec :) It was probably my fault.

Hi shiwo,

We must handle "non-standart situations" much better :)

It seems like problem could be reproduced if "Enable 32-bit applications" setting set to "true" for the application pool, used by Task Server. May you check such setting state in your environment?

Hi Alex,

it is possible. Default pool has this setting. In attached files you can see two printscreens

adv_settings_defaultapppool.PNG - the altiris site has been previously attached here

adv_settings_classicapppool.PNG - this pool is used now

Thank you, shiwo!

We believe this setting is responsible for the problem - error "Unable to read install directory from Software\Altiris\eXpress\TaskServerSetup" has been reproduce by one of our support engineers and I also see it on my server if Task Server appool modified with "Enable 32-bit applications" set to true.

Maybe you could remember the reason for such customization?

Alex.

You're welcome, happy to helped.

I'm not the only user of the machine, where the SS is running, so I don't know who or what changed this setting and why. But nothing special runs on machine, it is used as file server and SEP GUP, IIS is used only by Altiris.

OK, understood. Thank you again for the cooperation, shiwo.

So far this problem described in KB http://www.symantec.com/business/support/index?page=content&id=TECH213037 .

Hopefully we will make task server setup smarter in the next release.

Regards,

Alex.