I find it sometimes necessary to enable remote desktop (RDP) after a machine has left the building. As long as the machine is VPN’d in or somehow connected to the network, I can fire up a couple commands, few clicks, a reboot, and then I’m free and clear.
Open RegEdit (start >> run >> regedit)
Navigate to: HKLM\System\CurrentControlSet\Control\Terminal Server
Change the DWORD fDenyTSConnection to 0 (not 1)
Reboot the machine (shutdown -m \\computername -r -f -t 20)
I forgot to add an important step, namely the step after opening regedit. You must File >> Connect Network Registry, and then type in the name of the computer. THEN you can navigate to the HKLM.
I recently installed Vista on my main rig (long story short: old rig died, bought new rig). Everything was installing peachy, it might even be considered “fast”. No SATA drivers were needed, no other drivers were needed either. I’m still using on board video, but there’s a spot for a x16 PCI Express card.
Well anyway, installed the Vista, did all the Vista updates and installed all my 2007 software. Everything was moving along at a quick pace until I tried to load up Office over the network. Even navigating to the shared directory “Microsoft” was painfully slow. I attempted to copy the ISO over. I say Attempted because I didn’t even let it finish. It was moving at a snail’s pace: 16KB/sec. I can freakin DOWNLOAD it faster than I can grab it off a network share! WTF mate!
So I figured it was a problem with the network settings. I changed them from autonegotiate to Full Duplex. Then to Half Duplex. I even got rid of the IPv6 and VLAN settings, which did absolutely nothing. I finally hooked the system up to my Ghost Server and attempted to copy over a 3GB Ghost image. It flew by at around 21MB/sec. Twenty-one Mega Bytes versus sixteen kilobytes. Thank you network.
I narrowed it down to a couple possibilities – the Ghost Server was on it’s own unmanaged 10/100/1000 switch. The Applications server is on a managed Cisco switch with several VLANs. It only ran/runs slow on the managed network.
Here’s the fix now that I made you read all of my ramblings:
Somehow get to the administrative CMD. I edited quite a few settings on Vista already to allow me to administer the computer without that annoying popup. It used to be Start >> Run >> CMD. It’s still that in my edited version.
Then type “netsh interface tcp show global”. This will show the current netsh configuration in case you break something later.
Type “netsh interface tcp set global autotuning=high”. This will set it to a high rate of speed instead of the normal rate. Other configurations include “low” and “disabled”. I’ve heard some have had luck with disabling the autotuning completely. Be sure to repair your network connection. Oh wait, you can’t by normal means (thank you Vista again!).
In the command prompt, type “ipconfig /release” and then “ipconfig /renew”.
Had this issue appear when we Ghosted from a 36GB Server to a 147GB Server. Was running Sharepoint Services for internal use on the server, and none of the applications (administrative or otherwise) would run. Checked permissions, did all the Windows Updates. Notta.
Then I happened across a small Microsoft Issue when dealing with .NET1 and .NET2 on the same server.
Quick repair for .NET2:
1.) Start >> Run >> CMD
2.) cd C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727
3.) aspnet_regiis -ir
4.) Reload your failing page
Quick repair for .NET1:
1.) Start >> Run >> CMD
2.) cd C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322
3.) aspnet_regiis -ir
4.) Reload your failing page
As you can see the command is the same between the two versions of .NET. This fixed the issue, but it may not work in all cases. Check the permissions and the log files from IIS to see where the problem is.
The reason that the links between the applications and .NET failed was when I did an overlay Windows repair after ghosting to a new machine. Look up Ghosting Issues for more details.
Another issue from the new Exchange 2007 environment: permissions problems in terms of OWA setups. Basically every time one would go to our webmail OWA site, it would give a 404 error, or sometimes it would go through to authenticate but then say the session has timed out. Not good.
The quickest way to fix this is to just recreate the virtual directories. Here’s the low down on how to do just that:
1.) On your exchange server, open up the PowerShell command
2.) Type Get-OwaVirtualDirectory. This will list all of the virtual directories on any of the exchange servers currently in your domain.
3.) Type Remove-OwaVirtualDirectory -identity “owa (Default Web Site)”. This will remove the OWA directory in about 10 to 30 seconds.
4.) Type New-OwaVirtualDirectory -OwaVersion “Exchange2007” -Name “owa (Default Web Site)”. This will create the Virtual Directory again.
If you get an error saying that the IIS Virtual Directory can not be created at line:1 char:24, go into your Exchange Management Console. Under Server Configuration/Client Access make sure that Outlook Anywhere Enabled is set to FALSE for the server you’re trying to recreate the directory.
I found out on our second server that I really don’t need to type with capital letters. and since i’m lazy, i stopped typing with capital letters. thank you!
Working where I do gives me the opportunity to work with the latest and greatest of technologies. Exchange 2007 is, in my opinion, a huge improvement over 2003 in terms of speed. However, it moved too far away from the familiar GUI (like vista did), and therefore some usability has suffered.
Because Exchange 2007 requires 64 bit processors (or at the very least an Intel processor that emulates 64 bit technology), Windows Server 2003 X64 is needed. This means that Exchange will use up as much RAM as it wants to (10 out of 12GB on our server). It also means that .net 1 and .net 1.1 DO NOT work well with it. There are scripts that enable IIS to support 32 bit processes, but who wants to muck up the works with 32 bit and 64 bit processes fighting for resources?
If you accidentally install the Windows update hotfix .net 1.1 on your exchange server (I know I did), then it will automatically convert your nice 64 bit Exchange server into a 32bit mixed-mode Exchange server. Which might not be bad, except for the fact that IIS doesn’t like to mix modes. And that takes me to the point of all this writing – IIS does NOT like 32bit and 64bit.
When the hotfix made Exchange go into mixed-mode, IIS freaked out and stopped supporting OWA (outlook web access). It hosted a site called “Service Unavailable”. Not very creative. And through lots of searching, I came upon a set of instructions that is quite easy and works every time I replicate the issue.
1.) Uninstall Hotfix 1.1. If you really need .net 1 support, you’ll have to look elsewhere. .net2 works just fine. It’ll ask you to reboot the server, which sucks.
2.) Uninstall .net 1.0. Read above if you really require .net 1 support.
3.) On your exchange server, run this from the command line: “%SYSTEMROOT%\Microsoft.NET\Framework64\v2.0.50727\aspnet_regiis.exe -i”
If you get an error indicating that IIS is in 32 bit mode, go to step 4, otherwise go to step 5.
4.) ONLY TYPE THIS IF YOU GOT AN ERROR. “cscript c:\inetpub\adminscripts\adsutil.vbs SET /w3svc/AppPools/Enable32BitAppOnWin64 False”
This will make it so you are in a pure 64Bit environment again. After a couple minutes, go to Step 3 and run that command again (it will pass this time).
5.) Restart IIS. Check your OWA or Exchange web access.
I came across this issue when we had an employee with a personal computer (that turned into a work computer) leave the company. I had to remove all the work applications and put the computer back to the state it was before we applied all the group policies and such to it.
As a side before we start, I know that I could just reformat the machine and then reinstall the drivers. But that just takes too long. Uninstalling 4 applications, removing the computer from the domain, and performing a few other tasks takes about 15 minutes to accomplish.
Here’s how to disable folder redirection with My Documents synchronization:
1.) Open MMC (Start >> Run >> MMC)
2.) Control M to add a module
3.) Alt D to add the snap-in module
4.) Navigate to Group Policy Object Editor (or a similar name)
5.) Click Add, and then finish (you’ll want it to be on the local machine anyway)
6.) Click Close, then OK
7.) Navigate to Local Computer Policy >> User Configuration >> Administrative Templates >> Network
8.) Disable Synchronize all offline files when loggin on, logging off, and before suspend.
Here’s the full error:
The Login User Interface DLL CSGina.dll failed to load. Contact your system administrator to replace the DLL, or restore the original DLL.
This happens when you uninstall, and sometimes install, the Cisco VPN client. Cisco VPN client adds a registry key that disables fast user switching and loads the client before booting into Windows.
The fix below requires editing your registry files. If you have no idea what a registry file is, you probably shouldn’t be editing them. If you edit incorrectly your computer may refuse to boot. Here’s the quick fix:
1.) Reboot the machine
2.) Press F8 to load up the boot options menu for Windows
3.) Select Safe Mode and then select your Windows Installation
4.) After Windows loads into safe mode, it’ll ask if you want to continue working in Safe Mode. Select Yes.
5.) Start >> Run >> “regedit” (without the quotes). Press Enter.
6.) Navigate to
7.) Look for the GinaDLL Key
8.) Select and delete this key. DO NOT delete the entire Winlogon folder of keys.
9.) Close Regedit and reboot the machine
This is actually the most popular post on it.thelibrarie.com! Awesome!