DirectAccess is a great technology and I love to use it. If I get connection problems, I just open up my command line and examine the ipconfig output to see if something’s wrong. But is this something all your customers and colleagues are capable to do? I think not. Especially in rather large deployments, DirectAccess might put your help desk under a lot of pressure.
To reduce such calls and ease the complexity of debugging actual problems, Microsoft’s DirectAccess Connectivity Assistant might come in handy. It’s a small tool that notifies the user of his current connection status and helps to provide valuable information to the help desk.
So let me show it to you in action.
After setup it will show up in the user’s tray bar.
A simple single click informs about the current status (as does the tooltip).
A right-click offers two options: “Advanced Diagnostics” and a DNS preferation setting (we will come to that later)
The “Advanced Diagnostics” window offers more detailed information about the status and will generate log files upon its launch. Those can be send via the “Email logs” button to a prespecified address. It also has a link to your company’s help desk web page.
You will need to use the supplied ADMX/ADML files to configure the agent via Group Policy.
To do this, on your Domain Controller, copy the “DirectAccess Connectivity Assistant GP.admx” file to the folder “%systemroot%\PolicyDefinitions” and then copy the “DirectAccess Connectivity Assistant GP.adml” file to the folder “%systemroot%\PolicyDefinititions\language”. For example “%systemroot%\PolicyDefinitions\en-us” or “%systemroot%\PolicyDefinitions\de-DE”.
After that, you can launch the Group Policy Management MMC, open your DirectAccess GPO and navigate to “Computer Configuration / Administrative Templates / DirectAccess Connectivity Assistant”. You can now specify a couple of settings needed to use the tool.
At this point, I would like you to read the Deployment Guide supplied with the download, as it will help you to successfully deploy and configure your Assistant.
A customer of mine uses Microsoft BitLocker encryption to protect all it’s computers, both mobile and workstations, as they contain critical financial information of several other companies. When upgrading their client environment to Vista, we already introduced BitLocker for all hard drives and it worked like a charm. As they now move on to Windows 7, an interesting problem occurred for one the workstations when trying to encrypt a secondary drive.
Bitlocker encrypted OS drive
Whenever the administrator deployed the encryption task sequence via ConfigMgr, the hard drive disappeared from the system. There was no sign left at all, no drive letter in explorer, no entry in the management console and no trace in the device explorer. Gone! Looking at the activity LEDs, there was nothing going on. Restarting the system brought the drive back, but it did not continue to encrypt. Restarting the encryption led to the same behaviour. Looking at the drive’s BitLocker status revealed it began it’s work as it showed a 1% encryption. Decrypting it, again, let the drive vanish.
After some resultless research the final solution was to update the SATA Controller’s driver with the most recent one, in this case from the chip manufacturer, not the workstation vendor. After updating it, the encryption worked flawlessly.

Categories
Tag Cloud
Blog RSS
Comments RSS

Void « Default
Life
Earth
Wind
Water
Fire
Light 