I need to change the case of a user’s logon name from TUser to tuser. Seems simple enough but turns out there’s a little trick.
I open up the properties of the user & select the Account tab.
I change both fields to tuser & click OK.
I open the properties again to double check & notice that the User logon name (pre-Windows 2000) changed but User logon name did not.
The trick is to rename the account without actually renaming it. Right click the account & select Rename.
Now retype the name exactly how it currently is & press Enter. So in my case I just type Test User & press Enter. That will bring up the Rename User dialog box. From there change the case in the User logon name textbox (& pre-Windows 2000 if not already done) & click OK.
Look at the properties of the account & the case had been changed.
This is one of those stupid simple ones but when it happens again a year from now I won’t remember. When you go to print the Job Storage tab missing from your printer properties?
Looking at the properties of the printer I notice that Printer Hard Disk is set to Not installed.
I change it to Installed.
I look back at the Printer Properties & there it is.
Job Storage related links:
From my home network I signed up to watch a webinar. As is typical when registering for a webinar I was provided the option to download an ICS file to save to my Outlook calendar. I clicked the link to open the ICS file & Outlook 2010 (which was already open) hung for about 3 minutes then finally displayed the appointment.
I closed the calendar item then clicked the link again only this time I saved it to my desktop. I double clicked the ICS file & same thing. Outlook hung for about 3 minutes.
I run Process Monitor & open the ICS file again to get a capture. After the appointment opens I stop the capture. I set the filter to only show Outlook.exe. In a case like this where I’m not really sure what’s going on I go through each of the utilities on the Tools menu. Nothing is really jumping out at me until I open Network Summary.
What’s with Outlook connecting to these various IPs? I flip over to Process Explorer, open the Properties of the running Outlook process, & select the TCP/IP tab. I open the ICS file again. To my surprise I see Outlook making all these connections for the next few minutes.
Well this should not be happening. My Outlook profile is configured to connect to a CAS array which does not have a public DNS record. I run a DIG to see what’s getting resolved. (I’m using alternate info but the results are the same with my production FQDN.)
Yeah, that’s not right. I should be getting a status of NXDOMAIN & no answers.
So what’s going on? DNS Hijacking or as Cox Communications likes to call it…”Enhanced Error Results”. I’ll post some links below for further reading but in a nutshell, DNS hijacking means that when you browse to a website (i.e. query DNS for an FQDN) that does not exist the DNS server returns an IP address instead of an NXDOMAIN error. Since you received an IP address your browser will go to that site. A chill should have just gone down your spine.
In my case Cox was gracious enough to post an article on how to “opt-out of enhanced error results”. I have to hard code two alternate DNS servers in my router. Once I made the change & renewed my IP settings I did another DIG.
Much better. I open the ICS file & it pops right up. “Problem” solved I guess. Of course I wish Outlook would handle this a little better. I have been unable to find a KB article addressing this issue but if you know of one please leave a comment. One day when I have some spare time I might open up a case with Microsoft about it.
Links & what not:
Now before any DNS hijacking huggers out there say anything I’m well aware of this draft RFC but it’s expired therefore RFC 1035 & 2308 take precedence. Even ICANN thinks it’s a bad idea. See here & here.
You can also read up on the subject here.
Warning: This post deals with editing the registry. If you don’t know what that is stop right here & ask someone else to help you. Using the registry editor incorrectly can cause serious problems that may require you to reinstall Windows. Use the registry editor at your own risk.
Everytime a user tried to log into any of the Terminal Servers she got an error that said, “The Group Policy Client service failed the logon. Access is denied.”
No one else was having the issue on any of the Terminal Servers.
Long story short, her roaming profile was bad. What you can do to verify is open Regedit & mount (e.g. Load Hive) the user’s ntuser.dat file to a temporary key name. Look at the permissions of that node.
Yeah, that’s all messed up. It should look more like this.
So in my case I renamed her roaming profile on the file server from username to username.bak & had her try to log in again. It created a new profile & all was good. Had to reconfigure a few things once she was logged in but redirected folders took care of most of the things that would have gone missing.