Hi Adrian

The only issue known with Remote Desktop Connection is to work at session 0 (Zero) by adding the switch /console at the command line or the shortcut

(it is important for any kind of work on the servers)

Mike

Mike,

That is what I have been doing, but with the /admin switch for the newer RDC.  I was just wondering if others had problems because of using RDC or if everything had run smoothly for them.  Out of 5 SEPMs I have one that is problematic and the first thing mentioned was that it was because I installed it via RDC.  I installed 3 of the other ones using RDC and there were no problems at all.  I just think that to visit each server directly to migrate to a new SEP version is time consuming and lengthens the amount of time needed to finish a migration. It would be much simplier to send out copies of the install media to the offices and running it remotely through RDC from the main office.

Thanks.

Adrian

Hi Adrian

What SEPM and SEP client are you using?

I a, not familiar with that switch (I use mstsc.exe Ver 6.0.6000.16386).

Is there someone else connectining to this server via terminal? If so please refer to this solotion :

1.    Each user session will by default load SmcGui and ccApp (and ProtectionUtilSurrogate if the server is 64bit)

2.    These processes take memory and CPU (multiple SmcGui’s can result in 100% CPU usage)

3.    Neither are required for SEP to “function”

In order to prevent SmcGui and ProtectionUtilSurrogate from loading, perform the following steps:

1.    Logon to the server you wish to configure with an administrator account

2.    Click Start, Run and type “smc –stop” then click OK.  Enter a password if prompted.  Wait for the shield to disappear from the system tray

3.    Browse to the SEP Client installation location (normally C:\Program Files\Symantec\Symantec Endpoint Protection)

4.    Find the file SmcGui.exe and right click it

5.    Click Rename

6.    Rename the file “xSmcGui.exe” press Enter

7.    Click File, New and select Text Document

8.    Call the document “SmcGui.exe” press Enter

9.    At the prompt to change the file extension, click Yes

10. Click Start, Run and type “smc –start” then click OK.

11. You will notice from Task Manager that SMC starts as SYSTEM, but SmcGui does not load.

In order to prevent ccApp from loading (if you really must, we are talking 1MB 99% of the time per user):

1.    Logon to the server you wish to configure with an administrator account

2.    Click Start, Run and type “regedit” then click OK

3.    Browse to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run (for 64bit servers this is HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run)

4.    Find the entry ccApp and delete it

What do I lose?

·         If you prevent SmcGui from loading, there a few things you lose:

o    No SEP icon on the system tray

o    No ability to open the system logs from the client GUI (we have a separate logviewer utility that works though)

o    No ability to see the firewall or SNAC status from the GUI (but most people won’t install a firewall on their Citrix server!)

o    No startup scans

o    No delayed threat detection notifications

o    No missing or out of date definition notifications

·         By preventing ccApp from loading, you lose:

o    No notifications of POP3/SMTP/Email scanning for users

Mike

How would it work using pcAnywhere or similar??

Mike,

Thanks for all the info.  I am using mstsc.exe Ver 6.0.6001.18000, the one that comes with XP SP3.  With this version there is no /console switch.  It seems to have been replaced with /admin.  I am the only one that should be connecting to the server remotely.

I am currently in the process of migrating toward MR4 because we had a number of problems with MR3.  The MR4 install seems to have gone well at the main office.  Now I have to work on migrating our branch office servers.  I guess I am going to do the upgrades locally as the tech suggested.

Have you done any of your installs or upgrades using RDC?  Did you have any issues that came about because of using RDC to install or upgrade?

Thanks again.

Adrian

Our SEM servers are VMWare (virtual servers)

I used the VMWare console to get direct console connection and upgraded the manager from MR3 to MR4.

That went well.

I then assigned a package to the client group, removed the MR3 package that was assigned and made and assigned the MR4 package, and set it to update over 3 days for the weekend.

I came in today and almost all are on MR4 now. I did the same for the servers running MR3 of SEP - they are now on MR4 as well.

It was only the 2 management servers I had to "console" into.

I've always used Remote Desktop (RDP) for server work, very rarely is their an issue.  I've successfully installed SEPM via RDP a couple times too.  However, a DESTROYED my SEP installation, and almost took my domain controller with it, when doing an SEPM uninstall.  Check this out:

https://forums.symantec.com/syment/board/message?board.id=endpoint_protection11&thread.id=21945

So I would NOT use RDP to uninstall SEPM. BTW, it fors fine with the SEP client, no issues there, but I should note I don't use the Symantec firewall.  I think the firewall is the source of a lot of these ills.

I concur with David.  I hosed the database trying to upgrade via RDP.  Also, while it may be OK to upgrade clients this way in most instances, bear in mind that on Vista specifically it's been a no-no in the past, though that may have been addressed in MR4 (check the release notes to confirm).

Well, the consensus seems to be that installing or upgrading the SEPM through RDC is not a good idea.  That confirms what Symantec has told me.  I guess I'll make sure to do all my future upgrades locally at each of the branches.

Thanks.

Adrian

I know Symantec will always say installing via RDP is a problem (Backup Exec too), in my experience, I have not had any problems installing/upgrading via RDP (one SEPM, two replicated servers, 200+ clients).  Yes, I've had my share of problems with SEP but nothing that I could say was via RDP's fault.

BTW, the /admin switch does not give you a *true* console session.  This is by design.

"BTW, the /admin switch does not give you a *true* console session.  This is by design."

Rick, what does that mean?

It means you are not able to connect to session 0 via RDP which is a true console session.  Search these forums and you will find the same response.  The /admin swith will give you a console session, just not session 0 for security reasons from MS.

https://forums.symantec.com/syment/board/message?board.id=endpoint_protection11&thread.id=3297&view=by_date_ascending&page=5

>> I've successfully installed SEPM via RDP a couple times too.  <<

Hardly scientific or true testing. I'd not base anything on that.

"The only ravens I've seen are black, therefor, all ravens are black".

I used RDP in our original setup.

Had a number of strange issues. Can't say or prove one way or another that doing it that way was the problem. Symantec said it probably was, however, we've used that process for YEARS and thousands of times, thousands of installs with NO apparent (note that key word) issues. So far, they are the only ones stating it is or can be a problem.

I can understand their logic, it makes sense, and it's a known thing that you are not really working with the core of the OS and registry that way.

Here's my take - it's their product, their testing, their notes, their programming/code. IF they say it's an issue, and you still do it that way then have problems, they are within their rights to suggest that doing it that way MAY be a possible cause of the issues.

Especially if they can point to testing and/or research showing that people who install and maintain via a true console connection don't have the same issues........

So I now use the VMWare console connection. Funny, the management peice actually worked better doing it that way! Things worked that didn't work before. Coinsidence, possibly, very possibly.

(sorry, my spelling sucks this early in the AM)

I have just successfully installed via RDC.  Only problem I had was installing to a non-default directory.  This was corrected by adding the Authenicated Users group to the install directory.  After that everything has been working just fine.