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.

DirectAccess Connectivity Assistant in traybar

A simple single click informs about the current status (as does the tooltip).

DirectAccess Connectivity Assistant balloon

A right-click offers two options: “Advanced Diagnostics” and a DNS preferation setting (we will come to that later)

DirectAccess Connectivity Assistant right-click menue

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.

DirectAccess Connectivity Assistant Advanced Diagnostics

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.

One question is always asked: what about the performance loss?  I don’t have much knowledge about how exactly BitLocker works under the hood, but I of course had the general experience that BitLocker secured systems are not slow at all. So I got myself a second hard drive for my notebook and ran a small test to clarify this question based on my hardware. This benchmark was mainly intended for me, but I decided to share the data anyway.

The test machine:
Lenovo ThinkPad T61, Intel Core2Duo T7500 2.2 GHz, 4 GB RAM
Hitachi HDD, SATA, 2.5″, 100 GB, 7200 RPM
Windows 7 Enterprise x64

I used ATTO as the benchmarking tool. The test process was simple: two runs without BitLocker, two runs with it.

The Result

For the read-performance there wasn’t a real performance drop, as you can see in the screenshots.
The write-performance dropped by about 4.5%. In my opinion, that isn’t bad at all. I’ve seen worse results for TrueCrypt and others, but I don’t want to compare software here.

Now of course, one has to decide how to interpret the result. Obviously it is limited to the used hardware, but I would say it won’t be any worse on a ThinkPad T500. Then again, this was a synthetic benchmark which does not reflect the normal workload or work-pattern. Anyway, my “feeling”, the performance-loss cannot be high, is backed up.

SharePoint: Access Denied

The first suspect was of course the main user and group setting of the portal. But nothing had changed and the “freelancer” group still had it’s permission to view the homepage. As the access rights were inherited down to the time sheet manager, which was accessible, that couldn’t be the problem.

Then I noticed that one particular thing was different with the URL displayed in the IE address bar. Instead of the usual
” https://www.someportal.com/_layouts/AccessDenied.aspx?Source=%2fsomepage ”
I got this:
” http://www.someportal.com/_layouts/AccessDenied.aspx?Source=somepage&Type=list&name=%7B12151589%2D7C0B%2D40DE%2DBD92%2DADB851B3D78E%7D ”

The additional GUID leads to some list, as you can see a little earlier in the URL. Now you can of course search you content database or, if you want to save time, use a little tool. For this case I stumbled upon this one: The Sharepoint Explorer by Ontolica. Run it on your portal server with an user that has full access to the site. This way, you can find the list in question quite quickly.

SharePoint Explorer

In most cases, identifying the list is the solution, as you then know where you have to review the permissions. In my case, this was a dead end, as the permissions were correct.

Going on, I copied the Windows user account of a freelancer and gave it full permissions. Looking through “their eyes” I found a new report viewer web part on the homepage which was targeted at the freelancer group, so I couldn’t see it with my account. This web part was added a few days earlier and obviously not tested properly. The “read” permission was not enough to display it, so the homepage was denied. I granted the freelancer group participation-level access to the report-item, which finally solved the problem.

After the SPS configuration wizard was done, I tried accessing the SharePoint Central Administration page… and got this:

 

 

I stopped looking at the event log at this point, what proved to be a time-costly mistake, more to that later. I started searching the Internet and found a lot of similar cases but none came close to mine. Most “answers” told you to disable IPv6. Seriously guys, this is NEVER a “solution”! It is at best a workaround… and won’t help in my case anyway. A little later I reviewed our MOSS documentation and stumbled across the solution: the application pool identity user did not have enough rights on the server. I forgot that using a “domain admin”-service account does NOT grant it the right to log on as a service! I really don’t like this behaviour as I like to start with a domain admin account and then, in case everything runs as expected, strip it to a least privileges account. So I added the service account to our server GPO and the application pool started and could reach the Central Administration site.

This is just another case of READ THE EVENTLOG CAREFULLY! There was a third entry I overlooked which even suggests the missing log on rights:

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.

1. Exporting the Forefront TMG RC configuration.
2. Uninstalling Forefront TMG RC from the server.
3. Installing Forefront TMG RTM on the server.
4. Importing the Forefront TMG RC configuration into Forefront TMG RTM.

Step one was simple enough. Just follow the TechNet instructions:

To export the Forefront TMG RC configuration

The deinstallation was not that easy, however. First, the TMG itself was deinstalled. Next the SQL Server had it’s turn, but failed with some wired errors. Unfortunately, I don’t have the logs anymore, so I can’t post them here. As the TMG wasn’t listed in the contral panel at “Installed Software”, I guessed I could try to install the RTM right away… and was wrong. It failed AGAIN when installing the SQL Server.

To solve this, I had to manually remove any SQL components left over and I renamed any SQL related directories under %programfiles% and %programfiles(x86)%. This time the setup did it’s work as expected and I imported the system-configuration back into the Firewall. At the first start, cancel the wizard and follow these steps:

To import the Forefront TMG RC configuration

At a first look, it all worked well. Internet-Access was available again and the Exchange started to receive and send E-Mails again. But my Microsoft Office Communicator 2007 R2 was unable to connect. Also, my virtual test-machine failed to establish the IPHTTPS tunnel for Direct Access while 6to4 apparently worked. The IPHTTPS tunnel the the most use way for us, so it had it’s importance.

Solution to the unresponsive Office Communication Server (OCS)

As a matter of fact, all settings were imported, but apparently NOT IN THE RIGHT ORDER. While the normal policies looked right, the network rules were ordered randomly. The rule regulating the traffic between DMZ and internal LAN (routing) was below a NAT rule and thus not functional. Restoring the original rule order solved the connection problem.

Solution to the nonfunctional DirectAccess (DA)

Let me note here, that we have both the TMG and the DA on the same machine, so this problem might be unique to this environment. I tried to open the IPHTTPS URL in the Browser and got a certificate error. As you may already know, certificates are a pain and absolutely important for any DA connection. I found out the wrong cert was presented to the client. So I checked the DirectAccess MMC and made sure the setting were correct. I even went through all four configuration panels and applied the newly generated config XML. But the certificate didn’t change. After endless tries, I surprisingly messed up the config so badly, that the wizard wasn’t able to apply it anymore and told me to undo the current configuration. I did as told and even had to manually remove both the DA GPOs left over. After that, I rebuild the config (with the exact same details as before)… and it worked. New GPOs were created and the right certificate was published. I don’t really know what went wrong, but this is how you can solve it.

Our company tries very hard to use the newest software available, so customers see it in action when our consultants work with them. But in the “real world”, the clocks don’t tick as fast. Most of the time we face companies that are now migrating to Windows XP and Office 2003… oh my. In order to stay “compatible” with their workflows, it can be very complicated to maintain both worlds in one notebook.

To ease this pain, I looked into the Microsoft Desktop Optimisation Pack, short MDOP. The MDOP is available for companies that have Microsoft Software Assurance. One part of it is App-V. It virtualizes a software package in order to let it run on systems where compatibility issues due to other installed software would occur. It is not a full operating system virtualization, it’s just the application itself, running in a sandbox. So the software has still the prerequisite to be compatible to your target machines.

This step-by-step guide shows you the basic workflow to create a virtual software package and distribute it to a client with the ConfigMgr, in this case Microsoft Office 2003.

The following environment was used:
“Test Client”
Windows 7 Enterprise x64
Virtual Guest (Hyper-V)
App-V Sequencer installed

“Productive Client”
Windows 7 Enterprise x64
LenovoT61 Notebook
App-V Client and ConfigMgr Client installed (as well as a bunch of other stuff)

“ConfigMgr Server”
Windows Server 2008 R2 Enterprise x64
Virtual Guest (Hyper-V)
System Center Configuration Manager 2007 R2 installed

Be warned, this is a very long, screenshot-heavy post. To view the pictures correctly, click on the little button on the top right corner of the header to increase the column width.

Let’s start up the App-V sequencer. I already copied the Office 2003 sources to the “clean” test client.

Click “Create a Package”

Name the package as you wish and click “next”. In this case we skip the advanced options. Please excuse the fact that some buttons are in German.

Please use a dedicated, cleanly installed machine. Any extra service or program that works in the background will but irrelevant data into the monitoring process. You may already know this problem if you ever have repackaged software. When you have all the data you need for the setup in place, click “Begin Monitoring”.

The wizard will ask you where you will install the software to. I created a 8.3 format compatible directory here and selected it.

Still, it bugs about an incorrect naming, I don’t really know why. In any case, this could only become a problem if you have multiple virtualized apps that have similar 8.3 directory names (you might want to double check on this information). Click “Ignore” here.

The sequencer will now scan the system state for later comparsion.

When it’s done, it will show the dialog below. You can now start the Office 2003 setup!

I don’t want to bore you with the Office setup, so I keep it to the important details. Be sure to choose the directory you created earlier in the process and select custom installation.

Choose every component the user will need later, as you cannot use the “install on first use” feature here”.

Wait until the setup is completed. After completion, you may patch the application. I installed the Office 2003 SP3 at this point. When you are done, click “Stop Monitoring”.

The Sequencer will analyse all changes made to the system. When it’s done, click “next”.

Now you can configure what monitored applications you want in the package and most importantly, what file type associations. In this case I removed all of them, so that the user only starts the old Office version when it is needed. Click “next” when you are done.

In the next step click “Launch All” to start all applications in the package. The sequencer will detect any additional dependencies.

When you’re done, all applications will be “checked” and you can continue by clicking “next”.

The wizard will now sequence all collected data for you.

You can now edit the package as needed.

You can preset the server path (not needed for SCCM deployment) and compatible operating systems here. Additionally you might want the sequencer to create a MSI and compress the package. Both options I do recommend.

No need to change anything here…

or here…

or here…

or here…

or here!

Finally, you have to save the package. In my case I created a share on the ConfigMgr Server for this purpose.

After the saving in complete, switch to your System Center Configuration Manager and create a new “Virtual Application Package”.

Click “Browse…” and point the dialog to your package’s manifest XML file. Click “next”.

Fill out the form as needed. Click next.

You now have to provide an UNC path where the package will be copied to. This location must be accessible by client computer agents, like your other distribution points. Click “next”.

Take note of this message and click “yes”.

Click “next”.

Click “next”.

And finally, click “close”.

If you never deployed virtual packages via ConfigMgr, you need to allow the Client Agents to do so. Open the properties for the “Advertised Programs Client Agent”.

Enable “Allow virtual application package advertisement” and click “ok”. It may take some time for you clients to get the new policy, depending on your environment.

You may now create an advertisement for the virtual package.

The distribution wizard is similar to the one for normal software. Advertise it to a collection of your choice.

A few “moments” later, it should appear at your client.

Download and start the advertisement…

and start your application!

Congratulations! You made it!

I really hope you could learn something from this and enjoy the benefits of virtualized applications!

So far, so good. This works well, until you upgrade to service pack 2! This will update the Client Agent and render it incompatible with the MSP file. Unfortunately, if you didn’t touch that software package for several months, you may forget about the MSP file. As a result, all your deployments will fail at the “Setup windows and ConfigMgr” task. Pretty simple: removing the MSP will solve the issue. The way to this solution took me a little longer than just a quick bing’ing, anyone who debugs System Center products knows what I’m talking about.

Here are screenshots from the smsts.log, which was logged on the failing client:

vSEC:CMS Key Tool

In the logon screen, it took Windows nearly 45 seconds to read the slowest card and ask for the PIN. Wow! There was no evidence against the card reader, nor the other hardware, as a slow card was slow on all test systems.

But what can you do? Format C! And C stands for “card”. The simplest answers are the best! A short “bing” later, I found a tool named vSEC:CMS Key Tool, provided freely by Versatile Security. With it you can set the smartcard’s PIN and AdminPIN, unblock the user’s passcode and manage certificates. In this particular case, I deleted the original cert and reissued it. And guess what: as good (fast) as new!

MP Error Log

We set up a VM and tried booting into PXE… with no response of the server. Restarting the WDS service didn’t do the trick. So I dug a little deeper and took a look at the logs in %programfiles%\Microsoft Configuration Manager\Logs. Interesting files to look at: mpcontrol.log and pxecontrol.log (use SMS TRACE to

PXE Error Log

view these logs, if you don’t have any other preference). The PXE log didn’t tell me anything interesting, it even logged successful self-tests! Funny, because the log in the ConfigMgr-Console told me otherwise: the PXE service was not responding. It also told me the Management Port was giving a HTTP 500 error.

After a lot of rebooting and error-hunting I came up with a “solution” to this problem. It seemed the service pack installation didn’t properly update the PXE and management point and caused the unresponsiveness of both service roles.

WARNING: You may already know it, but just to be clear on this: the Configuration Manager takes some time to do it’s work. So be calm and watch the application log for MSI events, stating a successful (de)installation before rebooting. This is true for both the ConfigMgr Roles and Client Agent.

I did the following to solve it:

• Removed the Management Point Role (in ConfigMgr)
• Reboot
• Reinstalled the Management Point Role
• Removed the ConfigMgr Client Agent (ccmsetup /uninstall)
• Removed the PXE Role (in ConfigMgr)
• Reboot
• Removed the WDS Role (Windows Server)
• Reboot
• Reinstalled the WDS Server Role (no configuration after that of course)
• Reinstalled the PXE Role
• Reinstalled the CCM Client Agent
• Reboot

Yes I know: lots of lots of reboots. You may skip them if you dare, please drop me a line if it work anyway.

After that, all components went to green in the system state view and the PXE service started to respond as expected.