Deployment Solution

Hi all is there anyway of hiding the mapped drives when in Winpe other than using the Keyboard lock?

Thanks, Catherine

Need more information on your requirement.

Whether you dont want to see mapped drive in automtion OR  you want to hide details of WinPE configuration.

Please elaborate !!!

I want to hide the mapped express share  whilst downloading an image, it is shown as minimized in the bottom right of the window and so if an unauthorised user wanted to they could maximise and access everything in the express share and change drives to the other mappings.

The only way to acheive this is through keyboard lock settings configured within WinPe Configuration.

No other option is available for hidding the mapped drive.

What it is that you fear your users will be able to do within WinPE that they could not do when logged into their windows computer once deployed?

look at files like sysprep that have the windows key and admin passwords to join the domain etc.

Our users would not be able to map to our express share from windows

A keyboard lock would resolve this outright. But let's assume you don't want to lock the keyboard for some reason. To answer your fears then,

1. Sysprep File
   The sysprep files will only be present on the machine once the image has been delivered to the computer. The scope for scavenging this data is therefore somewhat limited locally. So you're thinking about a savvy user navigating the express share, finding your sysprep file and looking at the contents.
   
   Good practice however is that should only use a domain join account whose rights are limited to adding computers into your domain (I know that many out there use domain admin accounts, and that's bad). That means should they find your sysprep file, it's not going to be much good to them.
   
   If that's still not good enough for you, then it's time to deconstruct the native Altiris jobs. I deploy images using my own script tasks cause I'm a control freak. These script tasks inject sysrep, the agent installer and the agent settings. Once you have this type of control, you can inject your domain account data and your product code on-the-fly. Your template therefore never contains this potentially sensitive data -it's all hidden in the database task..  
    
2. Express Share
   Fair point. The express share is available, but what is it that you worry that the users might do there? If you use a locked down account to deploy images, then security wise whilst they can see the DS binaries and image files there isn't really an awful lot they can actually do that's either interesting or dangerous.

Okay you have a fair point exactly what rights does the user require when I am creating my boot images. Ie at the point "enter the account infromation used to connect to the file server" I find if I do not use a user that has read/write access to the express share my jobs fail. And as the user does have read/write access to to the express share they could delete the whole share.

I work in University with thousands of open access computers and very clever students.

I understand. For delivering images, all you need is read access to the share as a whole and write access to the temp and log folders.

If you want to upload images as well with the same credential, I suggest having a specific uploads folder where this credential has write access (rather than giving read/write access to the entire images folder).

As an aside, I tend to create  'locked' and 'unlocked' automation flavours for 'risky' environments. This ensures that for certain types of imaging tasks you can be assured that the keyboard and mouse are locked out.