Video Screencast Help

Test for RDP during installation

Created: 24 Jul 2009 • Updated: 04 Feb 2013 | 21 comments
prwade's picture
35 Agree
0 Disagree
+35 35 Votes
Login to vote
Status: Implemented

The interactive installer for Symantec Endpoint Protection should test its environment for Windows Remote Desktop non-console session before proceeding to installation.  Non-console RDP can create problems during installation, see this Knowledge Base article:

Title: 'Installing, Managing, Replicating SEP or SEPM in an RDP or Dameware session is expected to fail.'
Document ID: 2008061215013248
> Web URL: http://service1.symantec.com/SUPPORT/ent-security....

Simply testing the sessionname environment variable for something other than console would be a simple test that would prevent avoidable problems.

Comments 21 CommentsJump to latest comment

Jeremy Dundon's picture

The world leader in endpoint security should be doing so as well.

+4
Login to vote
Zoidberg's picture

This is definitely something that should be in place since a non-console session install is NOT supported and can cause un-intended results.

+3
Login to vote
David-Z's picture

It would be great to see something like this implemented.

David Z.

Senior Principal Technical Support Engineer, Symantec Corporation

Enterprise Security, Mobility and Management

+3
Login to vote
sandra.g's picture

So many issues could be circumvented if true console session was verified before installation.

Symantec, Senior Information Developer
Enterprise Security, Mobility, and Management - Endpoint Protection

Don't forget to mark your thread as 'solved' with the answer that best helps you!

+3
Login to vote
Vikram Kumar-SAV to SEP's picture

After troubleshooting for hours..its frustating to find SEPM was installed on RDP session..
Everytime we have to check if it is RDP or session for doing everything...and if we miss it..you are really lucky if everything goes fine..

Vikram Kumar

Symantec Consultant

The most helpful part of entire Symantec connect is the Search button..do use it.

+3
Login to vote
AL76's picture

Software installer should recommend against non console RDP session, was just researching, and couldn't find any way to programtically do it. Meanwhile, I'm not sure why many administrators still falls into the trap of using a non console mode when administring their boxes.

Alan Lee

Sr Manager, Regional Product Management, APJ

Enterprise Security, Mobility & Management

0
Login to vote
prwade's picture

Environment variable; if the environment variable %sessionname% does not evaluate to console, user is in a non-console session.  Sometimes %sessionname% will evaluate to console when it shouldn't, so it 's not a foolproof test, but if %sessionname% is not console trouble is to be expected.

+1
Login to vote
sandra.g's picture

I believe that detecting user ID 0 would also be good method for verifying console connection, except I think that for Windows Vista and 2008, user ID 0 is reserved (see http://msdn.microsoft.com/en-us/library/bb203962(VS.85).aspx).

If a video game can do it, we should be able to.

Symantec, Senior Information Developer
Enterprise Security, Mobility, and Management - Endpoint Protection

Don't forget to mark your thread as 'solved' with the answer that best helps you!

+1
Login to vote
Danno_SM's picture

We on the SEP installer dev team share your frustration with regards to RDP detection and support with the SEPM installer. I won't go into details but Microsoft has changed the RDP API's three times over the years so proper detection is not as simple as one would think. You will be happy to know that we have implemented a robust RDP detection system in the SEPM installer for the 12.0 release. This functionality will continue into the upcoming 12.1 release and we are evaluating how to port it back to the 11 MR release branches.

+4
Login to vote
prwade's picture

Glad to hear it!

+1
Login to vote
Vikram Kumar-SAV to SEP's picture

Thats the best part of the idea section...where we actually get to hear from Devlopment team as well.. 

Vikram Kumar

Symantec Consultant

The most helpful part of entire Symantec connect is the Search button..do use it.

+2
Login to vote
Yesd0g's picture

as stated above.

+1
Login to vote
Kaleb_Taylor's picture

I wrote our remote install documentation for this release and this is as far as I can tell one of the biggest issues installing our customers face. Further I know that there are ways to detect this before install. System variables, user session queries etc. There is no issues installing in Console session as long as there is no other account restrictions placed against the User logged in. To warn against non console installs would save our customers a great deal of time and troubleshooting. Further the answer for this is to typically either run a repair and the manager and client locally or in console or to uninstall and reinstall fully depending on the level of damage we see indicated in logs. Why not just warn them not to in the first place. Very good points here!

+2
Login to vote
Danno_SM's picture

Kaleb where can I find your docs? Are you seeing issues with SEP, SEPM, or both? I have asked one of my installer engineers to spend the time to get a deep understanding of the various Terminal Service scenarios and how they apply to our software installations. We have a new effort underway to improve what we delivered in 12 for 12.1 and possibly port it back as well.

You might be interested to know that in Vista and 2008 Microsoft is trying to correct some of these issues on their side.

http://msdn.microsoft.com/en-us/library/aa368353(VS.85).aspx

“EnableAdminTSRemote

 

Beginning with Windows Server 2008 and Windows Vista, this policy no longer has any effect. An administrator can perform an installation from the console session of a terminal server. An administrator can also perform an installation from a client session of the terminal server.

 

For more information, see Terminal Services in the Microsoft Windows Software Development Kit (SDK).

 

    Operating systems earlier than Windows Server 2008 and Windows Vista: 

+2
Login to vote
Kaleb_Taylor's picture

Thanks Dan,

I did already know this though. This is where the issue lies from what I can tell. In PRE 2008/Vista scenarios a service installed in a non console session gets a flag set and a connection is made through COM I believe linking say in this example SEPM services in the non console sessions with required services (Say IIS) Running in session 0. This is per Microsoft's own documentation:

http://download.microsoft.com/download/9/c/5/9c5b2...

Because services run in Session 0, named objects created or opened by services are usually in \BaseNamedObjects\. However, if a user application assumes that it is running in the same session as the service and synchronizes with the service by creating or opening objects with the Local\ prefix (or no prefix, which defaults to Local\), the application no longer works as expected. This is because the create or open request is specific to that session (due to the Local\ prefix) and the objects that the application creates or opens are in \Sessions\<n>\BaseNamedObjects instead of \BaseNamedObjects\. The correct way for user applications to synchronize with a service is to explicitly use the Global\ prefix when creating or opening objects in \BaseNamedObjects\.

For some third-party applications, pop-up messages cannot be seen from a Terminal Services session. This is because there is a different security context or desktop for the connected session that does not display the application's pop-up messages. The pop-up messages in these instances will go directly to the console. If you need to see these messages, connect to the console session using Remote Desktop Connection from the command line or the Remote Desktops MMC snap-in.

This is where we have issues. Once the connection between the two services is broken then our service either quit working or do odd things. By that I mean things like creating damaged or corrupted client install packages. Malforming creation of XMLs etc. All of this of course would be dependent on services again running in Session 0.

Now while I am thrilled that MS has figured this out and fixed it in 2k8 and Vista many of our customers will be using XP and 2k3 until they are sunsetted. Therefore this issue unless we come up with a solution for our customers will persist with our installs for years to come. I have give this information to the head of development through one of my Supervisors. I hope that your team takes this seriously and investigates the issue further.

Thank you for your consideration of these facts.

+3
Login to vote
JRV's picture

FWIW, for the last several versions, Backup Exec Setup has posted a warning about Terminal Server sessions. Maybe it's not reliable in all cases, don't know. But it's caught me every time I've tried.

Maybe you just need to ask the folks across the hall if you can use their code!

+1
Login to vote
Aniket Amdekar's picture

Its a god thing they have already taken care of this in SEP 12 SBS. When you try to install in an RDP session, you get an error message.

Cheers,
Aniket

0
Login to vote
AravindKM's picture

I agree. I think this is an urgent requirement.

Please don't forget to mark your thread solved with whatever answer helped you : ) Thanks & Regards Aravind

0
Login to vote
JimW's picture

Adding in Amber

Jim Waggoner Director Product Management, Symantec Endpoint Protection, Enterprise Security Group, Symantec

0
Login to vote
Elisha's picture

This was implemented in SEP 12.1.

+1
Login to vote
John Santana's picture

Thank you Symantec !

Kind regards,

John Santana
IT Professional

--------------------------------------------------

Please be nice to me as I'm newbie in this forum.

0
Login to vote