Vista logged on with a temporary profile

Over the past few months we’ve had a few instances of users logging into their Vista machines and receiving a temporary user profile. We have a fleet of 55 Vista notebooks that we’ve been running since Jan 2008 and had this error 3 or 4 times on different machines and twice on one machine! We haven’t been able to work out what’s causing the profile corruption, its not clear if the users have had trouble shutting down their machines, BSOD, or something else. We imaged these machines pre-SP1, and this problem could be something to do with the pre-SP1 Vista issues. None of our Vista SP1 machines have had this error so far, touch wood…

The error logged in Event Viewer is EventID 1511:
Event ID: 1511 – Windows cannot find the local profile and is logging you on with a temporary profile. Changes you make to this profile will be lost when you log off.

The users are logged on with a temporary profile and receive a warning in the system tray to tell them that their changes to the temp profile wont be saved. With the machines that we’ve come across so far the original profile has been in tact and there as been no data loss, just the inconvenience for the user while they loose their machine for an hour while we sort it out.

By looking in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList you can see that the corrupt profile has been renamed and has a .bak appended to the SID.

Looking the error up in Google took me straight to the Microsoft KB947242 where they say the cause is:

“This problem occurs if the current user’s profile was accidentally deleted from the system.”

WTF?! That doesn’t exactly instil confidence in Vista and user profiles, fortunately we haven’t lost any data yet but it would be interesting to know what’s been causing this error for us and if their are many people out there that have had similar experiences.

This is a copy of the instructions from the Microsoft Knowledge Base Article 947242 to fix the problem. We followed these instructions, pretty easy, just a hassle, and haven’t had any issues with data loss from the original profile.
To resolve this problem, follow these steps:

1. Log on to the system by using an administrative user account other than the user account that is experiencing the problem.

2. Back up all data in the current user’s profile folder if the profile folder still exists, and then delete the profile folder. By default, the profile resides in the following location:


3. Click Start, type regedit in the Start Search box, and then press ENTER.
If you are prompted for an administrator password or for confirmation, type your password, or click Continue.

4. Locate the following registry subkey:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

5. Under the ProfileList subkey, delete the subkey that is named SID.bak.
Note SID is a placeholder for the security identifier (SID) of the user account that is experiencing the problem. The SID.bak subkey should contain a ProfileImagePath registry entry that points to the original profile folder of the user account that is experiencing the problem.

6. Exit Registry Editor.

7. Log off the system.

8. Log on to the system again.

Full details here on Microsoft Knowledge Base Article 947242

The temporary profile issue is one of two major profile issues we’ve had since migrating to Vista, will blog the other issue soon, and we are starting to look seriously at client backup and recovery options. The Altiris Client Management Suite and Backup Exec Desktop Edition has been recommended to us but would like to hear from anyone that can recommend this package, or something else, for a corporate environment.


Recently we updated our auto-proxy setup for the network when we rolled out our ProCurve installation with different VLANs and subnets etc. With the new setup we had the opportunity to create a guest VLAN for Student internet access where they use their own machines over our network. However, we needed to give the Students a different proxy address to other machines on the network. I thought I’d take some time and create a post to outline the steps involved to setup auto-proxy and the reasons why it such a good thing.

In the past we’d force proxy settings through Group Policy which was fine for Internet Explorer but not as successful with other web browsers. That used to be OK, but now everyone has the web at home and that doesn’t work too well when they still have the proxy address from work in their preferences.

For the auto proxy to be a success you need a DNS server with an entry for WPAD pointing to a web server, and obviously, a proxy server for web traffic. This is really easy to setup, and will let your users run their preferred browser while still running through your proxy.


Create a new DNS host record for WPAD to point to the server that will host the wpad.dat and or proxy.pac files:
Alias name: WPAD
Fully Qualified Domain Name:
Fully Qualified Domain Name for target host:

If your network clients support receiving their proxy address through DHCP you can set the autoproxy file under option 252. Note: the string value is in lower case

Set option 252 ClassID with String Value http:/wpad/wpad.dat

If your web server is something like IIS 6 that can be particular about MIME types then you will have to manually create the MIME types for the proxy config files:
.dat application/x-ns-proxy-autoconfig
.pac application/x-ns-proxy-autoconfig

The code below is the JavaScript which makes up the wpad.dat or proxy.pac file. We are able to assign a different proxy for the students and guest machines by using isInNet to check which subnet the client IP belongs to and return a proxy address for that subnet. Lines 4 and 7 below check if the client is connected via one of the guest VLANs/subnets and assigns the proxy address. All other network clients receive an address from the range are assigned the proxy address from line 10.

   1: function FindProxyForURL(url,host)
   2: {
   3:     if(isPlainHostName(host) || isInNet(dnsResolve(host),"","")) {
   4:         return "DIRECT";
   5:     } else if (isInNet(myIpAddress(),"","")) {     // Guest Wireless
   6:         return "PROXY";
   7:     } else if (isInNet(myIpAddress(),"","")) {     // Guest Wired
   8:         return "PROXY";
   9:     } else {
  10:         return "PROXY; DIRECT";
  11:     }
  12: }

Future updates include adding some proxy exclusions for intranet and other internal webs using shExpMatch:

if (shExpMatch(url,”**”)) {return “DIRECT”;}

The WPAD and Pac file need to be in the root of the default web site in IIS. If you try and move the files to another site in IIS then the connection to the file is broken, even if the path is still valid. This quirk has something to do with different browsers sending different information to the web server when they request the auto proxy. This is from Wikipedia:

“When automatic proxy detection is used, Internet Explorer sends a “Host: <IP address>” header and Firefox sends a “Host: wpad” header. This is unexpected behavior, therefore, it is recommended that the wpad.dat file be hosted under the default Virtual Host rather than its own.”

OSX Auto Proxy

The auto proxy in OSX seems to be only semi-automatic… from experience with some of our Apple machines on campus, you have to manually set the address for the auto proxy file under Safari –> Preferences –> Advanced –> Proxies: Change Settings and manually enter http://wpad/proxy.pac

More Info

FindProxyForURL has more information and examples

Exchange c1041721 Information Store error

We had a strange problem today with our main Exchange Server. The server is running Exchange 2003, Windows Server 2003 and on decent HP hardware. We noticed the problem when we had a call from Administration to say that emails weren’t leaving their Outbox in Outlook. After experiencing the same problem from our machines we restarted the SMTP service on the Exchange Server. This had no effect on the problem so we looked at the Information Stores in the Exchange System Manager, and received  a popup with something to the effect that the IS wasn’t running and the error code c1041721.

After checking that all auto-start services were running we scoured the Event logs and couldn’t find anything relating to Exchange and the problems we had. We thought that the issue began between 13:12 and 13:15 by talking to a few staff members and checking when email stopped flowing through the server.

After some quick Googling the consensus was to try restarting the Information Store service, even though it was running in the task manager and occupying RAM and CPU. The service timed out during the shutdown and went into an uncontrollable state so we killed the process for store.exe. We were able to start the Information Store service again, without issue and without a reboot. Our Outlook Exchange connections appeared happier, with some machines stating that the connection had been lost and restored, and email flowed immediately.

After the Information Store server started there were some interesting messages in the Event Viewer:

ExchangeSA EventID 9175 where the MAPI call OpenMsgStore failed with the following error: Microsoft Exchange Server computer is not available. Either there are network problems or the Exchange Server is down for maintenance. MAPI Provider failed. Microsoft Exchange Server Information Store ID no: 8004011d-0506-00000000

VSS EventID 8194 Volume Shadow Copy Service error: Unexpected error querying for the IVssWriterCallback interface. hr = 0x800706ba.

MSExchangeIS EventID 9665 The memory settings for this server are not optimal for Exchange.

ESE Backup EventID 905 Information Store (247004) Server registered: Microsoft Exchange Server / Microsoft Information Store (callback DLL mdbrest.dll, flags 0x103).

ESE EventID 300 Information Store (247004) BG Staff Mail: The database engine is initiating recovery steps.

ESE EventID 301 Information Store (247004) BG Staff Mail: The database engine has begun replaying logfile e:\Program Files\Exchsrvr\Admin Staff\E01.log.

ESE EventID 302 Information Store (247004) BG Staff Mail: The database engine has successfully completed recovery steps.

The VSS Event 8194 had been logged 5-6 times in a row before the ESE recovery events.  The Exchange Server runs ShadowProtect for server snapshots and takes an incremental backup every 15 minutes during the day. The last snapshot had been taken just before midday and a snapshot should have initiated around the time the Exchange IS went, effectively, offline.

Since starting the Information Store service Exchange seems to be running as normal. Although I am presently running the Data Protector backup for Exchange before resuming ShadowProtect backups. While I don’t think ShadowProtect was directly responsible for the problem, I think there was something happening between ShadowProtect/VSS/Exchange that went pear shaped and hung the Information Store? Googling “c1041721” and ShadowProtect or VSS brought up basically no results, I would be interested to hear from anyone else who has had this error, or something similar, come up.

Update: The Data Protector Exchange backup completed successfully and I restarted the ShadowProtect backups and it picked up from the last incremental backup without any problems.

Daylight Saving, ProCurve and Time Synchronisation

Setting the new start and end dates for day light saving on your switches before daylight saving started would have been excellent planning and forward thinking. However, if your like me and didn’t remember until you rolled into work on Monday morning, three weeks ago, then here are the commands to get your switches back under control.

If you have a time server on your network you can set your switches to sync with it, otherwise you can set the switches to sync with an external time server if your firewall allows.

switch# conf

switch# sntp server

switch# timesync sntp

switch# sntp unicast

switch# time daylight-time user-defined begin-date 5/10 end-date 5/4

switch# wr mem

If you have a time server on your network, substitute from line 2 with the name or IP of your time server

Error tracking can be tedious at the best of times, but if the time on your network and switches is correct and consistent across devices then the job is easier for you and your team.

“…. I got a fever”

Well, after finding all sorts of great information from technical blogs everywhere to help me with work, research or whatever, the time has come to cowbell2contribute and try and give something back.  I hope that in the coming months this blog will contain useful information and How-to’s on ProCurve, Blade and Proliant HP equipment, Vista, Exchange, Active Directory, VMware and other network or server equipment that might be useful. 

We have just finished the budgeting process for 2009 and, pending approval on some items, have an idea of the projects that I will be part of over the next year or so. This means I have the opportunity to document and share our migration to Exchange 2007 and Office Communication Server, the  rollout of HP’s ProCurve Identity Management (IDM), Network Access Control and any other interesting projects I stumble across.

Over the next few days I’ll update the About page with my contact details and a blurb about what I do and the kind of things I’m interested in.


I have to give props to the man responsible for inspiring/motivating me to produce this blog, the great man, Lachlan Hardy.

If you’ve seen the video from SNL, you’ll understand what I mean when I say,

“Guess what? I got a fever! And the only prescription.. is more cowbell!”


In the meantime I’ll get busy and finish some of the half written posts that I’ve started…

– Greg