Persistent Drive Mappings on Some Clients

[Clint]

We're only running Altiris 8.1 RU7 at the moment where there are a few desktops that have Y: and Z: drive mappings which can't be disconnected.  Looking at the folders/files, they all correspond to a share on the Altiris server which I use to copy software to for s/w delivery jobs and is also used as a general s/w repository (read-only for users) in case programs need to be manually installed for whatever reason.

Main issue is attempts to disconnect these mysterious Y: and Z: drive mappings have failed where they're not being regenerated by any logon script in the domain.  I'm guessing that for a s/w delivery job whereby the command line is just a UNC path pointing to the s/w repo on the Altiris server, it's temporarily mapping these drives but not disconnecting them afterwards for some reason.  Has anyone seen this behavior before on desktops with the Altiris Agent and know how to disconnect these ghost drive mappings?

[Roy B]

Hello Clint,

First of all, please note that 8.1 is no longer supported, and our latest version is 8.7.  Let Support know if there's anything we can do to help you plan an upgrade.

It sounds like you've created a Software Portal like repository.  Have you tried using our Software Portal?   Users can select and install packages as needed.

For the issue of lingering Mapped Drives, a Net Use command should clear them up: 

• net use x: /delete /yes
• net use y: /delete /yes

You can run that as a Command Script inside a Task and execute on systems as needed.

If you'd like to find out where these mapped drives are coming from, and also see if they are needed or not (usually not needed as the Agent downloads directly from the SMP or a Package Server), please open a support case, and we'd be happy to help you investigate.  We'd be happy to help you setup the Software Portal as well, if that's helpful.

Best Regards,

Roy

[Roy B]

First of all, 8.1 is no longer supported, so please let us know if you need any assistance reviewing an upgrade plan.  8.7 is our latest version and has been working very well.

Sounds like you've implemented a sort of Software Portal like repository.  If you haven't done so, please look into using the Software Portal.  That's exactly what the Portal is for.

I've never seen an issue where the mapped drive for lingers after s/w install is complete.  Maybe we're mapping the drive during s/w install?  That should not be necessary as the agent downloads files from a Package Server or the SMP using HTTP or UNC (it's already setup to do this with little Admin setup necessary.) 

Nevertheless a simple Net Use command should remove these mapped drives: 

• net use X: delete /yes
• net use Y: delete /yes

You could run that as a task and execute on systems as needed.

If you'd like personal assistance with s/w delivery, please open a Support case.  We'd be happy to research where these mapped drives are coming from, and see if they are needed or not, as well as help you configure the Software Portal, and answer any questions about using Software Delivery.

Best Wishes,

Roy