Your Profile was not loaded correctly error on windows 7

I’ve had a few instances lately where corrupt profiles have prevented me from logging into with a Windows 7 or Server 2008 R2 machine. At the time of logon, the logon process takes a while and then I get the following error:

Your user profile was not loaded correctly. You have been logged on with a temporary profile. Changes you make to this profile will be lost when you log off. Please see event log for details or contact your administrator.

Also in the Event Viewer (Application) you have an entry for Event ID 1511. Normally this isn’t a big deal because you can log onto the machine with a different admin account and delete the problem profile. Only in this case when you go to remove the profile it doesn’t exist. I came across the following Microsoft article – KB947242 that deals with this issue. If you open regedit and Navigate to:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfielList

You will find a list of profiles that are identified by their SID. Locate the SID of the account in question (It will probably be called SID.bak) and delete the entry. Log off of the system and log back in using the problem account.

System Center 2012 SP1 Drops

It’s been just over a week since the official announcement that service pack 1 for System Center Configuration Manager 2012 was released. This is a really important release for the System Center teams as SP1 really drives home the idea of unified device management. Service Pack 1 adds support for  Windows Server 2012 and Windows 8, Windows 8 tablet plus added support for Mac OS X, Linux and Unix platforms. This is exciting for our environment because there has always been a gap with managing the subset of machines running Mac OS X or Linux. Can you manage one of these platforms to the level that you can manage the Windows platform? No. However this is a step in the right direction. Admins want a single pane of glass view for managing their environment – SP1 moves System Center in the direction. Some other features of this release are support for Windows Embedded devices, full PowerShell support, Windows Azure based Distribution Points and the ability to subscribe to email alerts. 
When you dig a little deeper into the CM 2012 release you’ll find added support for user profile and data management with their new User Environment Virtualization product (MDOP 2012) and real time administrative tasks for endpoint protection, network cost support for application delivery, updates to Bitlocker including TPM and PIN, and the ability to deploy Windows 8 applications.

Troubleshooting a XenDesktop Issue... What do the Logs Say?

Over the years when working with System Center Configuration Manager you get used to combing logs to resolve issues. ConfigMgr has a log for everything so it was my surprise when I starting working with XenDesktop how limited logging is out of the box. After working through my first major outage, I quickly found out that logging is no good if it is not enabled. It’s not that XenDesktop doesn’t have logging it just doesn’t have enabled by default. I would highly recommend enabling the following logging in XenDesktop – on the VDA, on the DDC and PorrtICA.

Enabling Virtual Desktop Agent (VDA) logging (CTX117452):

• Change your vDisk to Private mode and boot your template machine
• Log in with an admin account
• Navigate to %ProgramFiles%\Citrix\Virtual Desktop Agent
• Backup WorkstationAgent.exe.config
• Open the configuration file with a program such as Notepad
• Locate the following section <appSettings> section  (Near the top of the config file) and update as follows:
• <add key=”LogToCDF” value =”1”/>
• <add key="LogFileName" value ="D:\XDLogs\vda_log.log"/>
• <add key="OverwriteLogFile" value ="1"/>
• Save and close the file
• Restart the Citrix Desktop service or reboot your template machine and confirm that the log file gets created

The above configuration will redirect the log file to the D:\ partition (Assuming that you have persistent disk) but you can change the location to whatever works for your environment. If you set to the location to somewhere on the C:\ drive ensure that you set the correct permissions. You can also configure the log to overwrite itself anytime that the Citrix Desktop Service starts. (Shown above) If you don’t set the log file to overwrite just be mindful of your disk space.

Enabling Desktop Delivery Controller (DDC) logging (CTX117452) with XenDesktop 5.6:

• Log into your DDC with an admin account
• Navigate to %ProgramFiles%\Citrix\Broker\Service
• Backup BrokerService.exe.config
• Open the configuration file with a program such as Notepad
• Locate the following section <appSettings> section  (Near the top of the config file) and update as follows:
• <add key="LogToCDF" value ="1"/>
• <add key="LogFileName" value ="D:\XDLogs\controller_log.log"/>
• <add key="OverwriteLogFile" value ="1"/>
• Save and close the file
• With XenDesktop 5.6 I did not have to enable logging for CdsPoolMgr.exe.config as outlined in CTX117452
• Restart the Citrix Broker Service (This will cause any virtual desktops connected to the server to re-register with another controller)

The above configuration will create a log file on the D:\ partition assuming that you have one. If you set the log location to be somewhere on your C:\ partition watch that your permissions are set correctly. Since the log file will only overwrite itself when the Citrix Broker service is restarted this log file can grow quite large. Personally I only enable this logging when I’m troubleshooting a specific issue and then I leave it disabled.

Enabling PortICA logging (CTX118837):

• Change your vDisk to Private mode and boot your template machine
• Log in with an admin account
• Navigate to %ProgramFiles%\Citrix\ICAService\XML (If the XML folder does not exist, create one)
• Create an new XML file called PorticaConfig.XML
• Paste the following into the file:
<?xml version="1.0" encoding="utf-8"?>
<Config xmlns="Portica.xsd">
        <Portica>
        <LogFile>
            <LogLevel>5</LogLevel>
        </LogFile>
        <CdfTrace>
            <LogLevel>5</LogLevel>
        </CdfTrace>
        <FunctionTrace>
            <LogLevel>5</LogLevel>
        </FunctionTrace>
    </Portica>
</Config>

• Save and close the file
• Restart the Citrix ICA service or reboot your template machine

You can change the level of logging with the following values 0, 1, 5 or 9 with 0 being the least verbose. Unfortunately you can not change the directory where the log file gets created so you if you use a standard vDisk that gets refreshed at every logoff you’ll need a shutdown script to copy the log to either a persistent disk or a file share. By default on Windows XP the log file is located at: C:\Documents and Settings\LocalService\Local Settings\Temp and on Windows 7 it’s located at %WinDir%\ServiceProfiles\LocalService\AppData\Local\Temp

There is also a logging tool that Citrix has published as outlined in CTX127492 that can enable more logging however I have solved most of my issues using VDA, DDC and PortICA logging. Regardless of how you setup logging a great utility to help you read them is Trace32.exe from the ConfigMgr toolkit. Download and install the tools and then open your log files with Trace – your eyes will thank you.

Where can I find that GPO setting?

Is there a policy for that? Would that be a computer based policy or a user based policy? If I can’t set that with a traditional group policy can I do it with a preference? When dealing with Group Policy Objects (GPOs) I find myself asking these types of questions all the time? Wouldn’t it be nice if there was a searchable site of policy settings? Sure you can Google settings and there are great sites such as www.gpanswers.com but I’m talking about a site that allows you to search for group policy settings, identifies where you can set them, explain what they do and most importantly what registry settings they touch.  There is. MSDN publishes a site that does this. Group Policy Search is a fantastic resource when dealing with group policies. When you search for setting the tool will provide you with the following information:

• Policy Name
• Category Path (Where you can find it in the console)
• Supported Platforms (What the minimal operating system level required)
• Registry Key
• Value
• Explanation of what the policy does

If you’re like me and deal regularly with group policy administration you’ll find this tool a huge time saver. And yes it has just been updated for Windows 8 and Windows Server 2012

WMI and the ConfigMgr Client

If you still manage Windows XP machines with ConfigMgr I’m sure that you know that 9 out of 10 client health issues are WMI related. Whether it’s the CCM namespace getting corrupt or the entire WMI repository getting corrupt... Windows XP WMI + ConfigMgr = unstable.
Most of the time you can get away with simply deleting the ccm namespace and then reinstalling the ConfigMgr client to correct the problem. (More on that later) However there are times when the fix requires you to rebuild the entire WMI repository – which should be used as a last resort as there could be other applications on the machine that rely on WMI.
After searching around for WMI resources I came across this post which does a great job of detailing different ways to resolve your WMI issues based on your Operating System version. I've used many of these approaches in order to resolve client health issues but I’ve had the most success with the following command:

• From a command prompt run rundll32 wbemupgrd, RepairWMISetup

If you decide that rebuilding the WMI repository is what you need to do follow these steps for Windows XP:

• Open a command prompt and run the following
• net stop winmgmt
• Browse to %windir%\System32\Wbem
• Rename the Repository folder
• Go back to your command prompt and run the following to rebuild your repository
• net start winmgmt

As mentioned before, If you rebuild your WMI repository you run the risk of breaking other applications on that machine that require WMI. A safer method is to simply delete the CCM namespace and then repair the ConfigMgr client. One tool that I now use almost exclusively is SCCM Client Center. SCCM Client Center allows you to do a variety of things but one of the most handy options are it’s client repair options. After you install Client Center connect to the machine in question, (Top left-hand corner) click on the Agent Action menu (highlighted in the screen shot below) and as you can see there are a bunch of actions that you can kick off to repair the ConfigMgr client. Most of the time selecting Delete root \ccm will resolve your problem.



I find myself using this tool everyday for a variety of reasons.