Kernel Confusion

Hi folks,

earlier this year we finally stepped forward and configured our Exchange 2010 to utilize Unified Messaging to support us with cool mailboxes and that kind of stuff. In the testing phase I installed the Japanese UM language pack to hear what it’s like. Now, as the server is in a productive environment, I wanted to clean things up and uninstall this pack as it’s not needed.

The TechNet has this to say:

In Microsoft Exchange Server 2010, you can manage UM languages on Unified Messaging servers using the Exchange Management Console or the Exchange Management Shell. However, to remove a language from the list on a UM dial plan, you must remove the appropriate UM language pack from the Unified Messaging server by using the Setup.com /RemoveUmLanguagePack command. After you remove the UM language pack from the Unified Messaging server, the language won’t be available when you configure a UM dial plan. You can view the UM language packs that are installed by viewing the properties of the Unified Messaging server or using the Get-UMServer cmdlet.

At this point you might stop reading the article, as the essential information, the setup.com-command, is quite simple. But when you try to execute this, it will fail like this:

d:\Program Files\Microsoft\Exchange Server\V14\Bin>Setup.com /RemoveUmLanguagePack:ja-JP
Welcome to Microsoft Exchange Server 2010 Unattended Setup
Preparing Exchange Setup
    Copying Setup Files
d:\Program Files\Microsoft\Exchange Server\V14\Bin>

It just quits right there, no error, no logfile and no event at all. Supplying the /s parameter for the language pack source does not help either. Here is the catch: the setup.com on your server is a DIFFERENT from the one on your Exchange 2010 DVD! You have to use the one on the DVD to succeed. This information actually in the TechNet:

If you run it from the DVD, it will look like this:

M:\>Setup.com /RemoveUmLanguagePack:ja-JP
Welcome to Microsoft Exchange Server 2010 Unattended Setup
Preparing Exchange Setup
The following Unified Messaging language packs will be removed:
    UM Language Pack for ja-JP
Performing Microsoft Exchange Server Prerequisite Check

Configuring Microsoft Exchange Server
    UM language pack for (ja-JP)     ......................... COMPLETED
The Microsoft Exchange Server setup operation completed successfully.

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.

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.

Bitlocker is a nice piece of security technology. My company, working mainly in IT consulting, uses only notebooks and of course needs to transport sensitive data from time to time. So, since Vista we use BitLocker to protect our valuable information from theft, e. g. in case of a stolen notebook. We also deployed it for some customers.

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.

Every last business day of the month, freelancers working for our company access our SharePoint Portal to enter their project work times. This time, they got an “Access Denied” error instead of the usual homepage. Trying to access “www.someportal.com” would result in the error shown below. On the other hand, directly accessing the time sheet manager via “www.someportal.com/time/” was successful.

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.

Today I installed the Windows SharePoint Services 3.0 SP2 on a Windows Server 2008 R2 x64 machine in order to install the Service Level Dashboard for Operations Manager 2007 R2 later on. I had to use the SPS because the SLD installer is incompatible with non-English MOSS farms… and Microsoft didn’t quite care about the users “whining” on TechNet.

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:

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.

Last night I had to upgrade our existing Threat Management Gateway RC machine to the final version of the product. According to TechNet this seemed to be a simple task, only a few steps are needed:

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.

Hello everyone!

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.

More »

2008 I installed a System Center Configuration Manager 2007 environment at a customer’s site. In the end, we had quite large task sequences with dozens of “install software” entries to automate OS deployments as good as possible. A “feature” of ConfigMgr was to wait 90 seconds in between each task. Imagine 50 software packages… and do the math. It took much too long. A hotfix (KB955955) was released by Microsoft and I deployed it on the SCCM Server. It extended the CCM Client Agent with a MSP file that is applied while the agent is installed. The 90-sec limitation was gone.

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:

Computers tend to get slower over time, the more you use it, the faster this will happen. But is this true for hardware as well? In this case: smartcards? I didn’t believe it until I got my hands on a few cards from employees that complained about very slow read times. Our company enrolled smartcards for Direct Access usage (and I love this Windows Server 2008 R2 feature!).

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!