Error Source: ACUpload   EventID:0

ACTUPLOAD: Microsoft.ApplicationExperience.Common.ObjectFramework.PersistenceException: Persistence_FlushSqlError —> System.Data.SqlClient.SqlException: The INSERT statement conflicted with the FOREIGN KEY constraint “Logical_Machine_OS_ForeignKey”. The conflict occurred in database “ACT-Demo”, table “dbo.OS”, column ‘osID’.

The SQL Key here indicated it tried something regarding the OS Key. So a quick look in my file showed this in the 5th line of the XML:

<OsInfo Id=”6.1.1” MacAddress=”…

I manually changed that number to 6.0.0 and the file got imported correctly. The machine was listed as Vista now. Version 6.1.0 is for Windows 7, 6.1.1 is for Windows 7 Sp1, but that’s nor yet in the ACT Database. Nothing serious, just for those of you how didn’t see that coming, like myself

A little searching didn’t help me, I even found a TechNet thread where a Microsoft colleague stated that there is no way to turn single gadgets on and off, you can just disable the whole feature.

As a techie I wasn’t satisfied with that answer and pulled Sysinternals Process Monitor out of my sleeve… well, a USB stick. If a user right-clicks a gadget in the list, he is presented with a uninstall option. Using this one will add the filename of the gadget to the settings.ini in “%userprofile%\Windows Sidebar”.

So my solution is to use a Group Policy (Extention) to edit the .ini-file as I need it. Look at the [Root] section and the “PickerDefaultPackageSkipList” property. There you can add all the Gadgets you don’t want to see in the list.

Example:

PickerDefaultPackageSkipList=”Weather.Gadget,Currency.Gadget,”

This will remove the Weather- and Currency-Gadget from the list. Of course, the user can still re-add this one, but you could also delete the files as well. From here you can customize the solution to your needs.

Go Go Gadgetto Blogpost!

I just had the “opportunity” to see a new one at a customer’s test site. It happened at unusual times, like in the middle of the image transfer or directly after it. The logs showed that the client was unable to reach his server. But why that? Physical connectivity was tested and ok and it never happened when running Windows 7 itself on the same machine.

It took me a bit because this one isn’t something you stumble upon everyday: the client lost his IP! Why? A DHCP lease time of 10 minutes! So, if a task took more than 10 minutes without a reboot, the IP was gone and the sequence ended in an error.

The lession learned here is that the DHCP Client in Windows PE doesn’t refresh his lease on time (or at all). Doh!

PS: Please don’t ask why this lease time was set at the DHCP server

With little effort you can extend the hardware inventory so you will get to know

• The total amount of DIMM-Slots
• The free amount of DIMM-Slots

To get your hands on this information, you have to modify the SMS_DEF.MOF on your primary sites. There are two WMI queries that need to run on the client. The first one gets detailed information about every installed module and the second one is used to determine the total and used slots on the mainboard. This is inspired by some wise guy from the myITforum.

The MOF-File in question is located in the following location: <smsinstalldir>\inboxes\clifiles.src\hinv

Be sure to make a backup and, to be on the safe side, do not test this in a productive environment. It’s unlikely that it causes trouble, but we should always fear Murphy’s Law!

Just add the following code at the bottom of the MOF-File and save it.

//**************************************************************************
//* Class: Physical Memory
//* Derived from: (nothing)
//*
//* Auslesen der Speicherinformationen pro installiertem Modul
//*
//**************************************************************************
[SMS_Report (TRUE),
SMS_Group_Name ("Physical Memory"),
SMS_Class_ID   ("Microsoft|Physical_Memory|1.0")]

class Win32_PhysicalMemory : SMS_Class_Template
{
[SMS_Report (TRUE)] string BankLabel;
[SMS_Report (TRUE), SMS_Units("Megabytes")]  uint64 Capacity;
[SMS_Report (TRUE)] string Caption;
[SMS_Report (TRUE)] string DeviceLocator[];
[SMS_Report (TRUE)] uint16 FormFactor;
[SMS_Report (TRUE)] string Manufacturer;
[SMS_Report (TRUE)] uint16 MemoryType;
[SMS_Report (TRUE)] uint32 PositionInRow;
[SMS_Report (TRUE)] uint32 Speed;
[SMS_Report (TRUE),Key] string    Tag;
[SMS_Report (TRUE),Key] string    CreationClassName;
};

//**************************************************************************
//* Class: Physical Memory Array
//* Derived from: (nothing)
//*
//* Auslesen der verfügbaren Speicherslots
//*
//**************************************************************************
[SMS_Report (TRUE),
SMS_Group_Name ("Physical Memory Array"),
SMS_Class_ID   ("Microsoft|Physical_Memory_Array|1.0")]

class Win32_PhysicalMemoryArray : SMS_Class_Template
{
[SMS_Report (FALSE)] string Caption;
[SMS_Report (FALSE)] string CreationClassName;
[SMS_Report (FALSE)] string Description;
[SMS_Report (FALSE)] uint16 Location;
[SMS_Report (FALSE)] string Manufacturer;
[SMS_Report (TRUE), SMS_Units("Megabytes")] uint32 MaxCapacity;
[SMS_Report (TRUE)] uint16 MemoryDevices;
[SMS_Report (FALSE)] uint16 MemoryErrorCorrection;
[SMS_Report (FALSE)] string Model;
[SMS_Report (FALSE)] string Name;
[SMS_Report (FALSE)] string OtherIdentifyingInfo;
[SMS_Report (FALSE)] string PartNumber;
[SMS_Report (FALSE)] boolean PoweredOn;
[SMS_Report (FALSE)] boolean Removable;
[SMS_Report (FALSE)] boolean Replaceable;
[SMS_Report (FALSE)] string SerialNumber;
[SMS_Report (FALSE)] string SKU;
[SMS_Report (FALSE)] string Status;
[SMS_Report (TRUE), Key] string Tag;
[SMS_Report (FALSE)] uint16 Use;
[SMS_Report (FALSE)] string Version;
};

As you can see, you can gather much more details if you switch some of the “FALSE” values to TRUE. The next time the client updates his policy, the new code will be compiled on the client. The next scheduled hardware inventory will execute the new queries and report the results back to the assigned site server. When this happens, two new tables will be created in the CfgMgr-Database. In this case, this would be:

• v_gs_physical_memory_array
• v_gs_physical_memory

Of course, this alone won’t help us so much. To make the data readable, we can create a report. I have created a report that combines both tables to show you the details of each installed module, enriched with the information how many slots there are and how much of them are still unused. Feel free to change the SQL statement to your needs.

Report Example

To make things easier, you can download the report’s .MOF-file for quick import into the CfgMgr.

Download: CfgMgr RAM Report MOF

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.

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.