TechFRP Search

Custom Search

Wednesday, March 23, 2011

Auto Login Troubles in Windows

     We have had a problem for some time now with the new PC's we've been getting. All of them are having difficulty properly logging into the Domain in situations where an Auto Login is configured. Regular manual logins by desktop users have no difficulty, but in situations that call for a PC that uses a predefined Auto Login setup, there are problems.

     When Auto Login is set there is no obvious error until you see that no network resources were mapped. Further investigation reveals that the system used "Cached Credentials" to log the user into the PC. It is like the network wasn't yet ready to accept connections but Windows was. The real problem is that any network resources like, the assigning of a home directory, the running of Login scripts and proper Domain Authentication do not occur. These network resources are accessible after the desktop loads but do not run automatically as they are supposed to.

     We found that if we plugged in a small Hub/Switch so that the PC went to the Hub first, then the Hub went to the Network jack, the problem did not occur. This wasn't a good solution though as we didn't want to have small Hub's all over the place. As a temporary fix it worked but we had to find what the real problem was. We called the Vendors that made the PC's (Big Industry Names) but not one of them could help at all with explaining why their new PC's were doing this.

     After a lot of research, trialling and testing we found a solution. The core of the problem was the New PC's. They were so much faster than the older models that Windows was ready to login before the network card had completed it's speed and duplex auto negotiation. The Auto Login setup will run as soon as Windows is ready and sees an active network. Even though the network link is active, it was taking another second or so before the Speed and Duplex was negotiated with the Switch. At that point Windows uses the Cached credentials because the Domain controller is unreachable. A second or two later the negotiation has completed and the network is accessible but not until after Windows login has occurred.

     We figure out two ways that you can Fix this problem. One would be to disable the Switch's Auto Negotiate settings for that Port. Set it to a predefined speed that is known to be good with the PC. This wasn't considered to be the best solution though because changes to individual Ports tend to be forgotten over time and if the PC is moved the Port will probably be left at the Static settings. The way we chose to correct the problem was to disable the Auto Negotiate feature at the PC. In this way you set the PC itself to the speed and duplex you know it is capable of, in our case 100/Full. Now if the PC is moved to another location it will still work in any Port/Jack and there are no changes required at the Switch.

     Once this was changed every Auto Login functioned correctly. The systems logged in, Authenticated properly with the Domain, mapped home directory assignments and completed the running of all login scripts. This setting may vary with Network card manufacturers but for us it is found under the NIC's Device Properties. Setting it to 100/full instead of Auto Negotiate resolved the problem entirely. By doing this you eliminate the need for interaction between the NIC and the Switch. It takes time for them to figure out the best settings to communicate. When it's statically assigned the network activation happens quicker. It saves you that second or two difference between Windows being ready and the Network being ready.

     If you are having similar problems and haven't been able to figure it out yet, give this a try and see if it solves your troubles. It did for us. :-)

     As always, I hope you found this useful. If you did, please leave a comment and let me know, I'd love to hear from you. Until next time don't forget you can always find me on Twitter @wjgtech.
Have a great day.

Thursday, March 17, 2011

How To: Expanding Windows 2003 Boot Volumes in VMWare

     I've been working alot with VMware lately and there's one thing that has always been difficult. How do you best expand Windows Server partitions from a deployed template? A Template is great but you don't want the hard drive partitions to take up unnecessary space. The problem is expanding those partitions to the size you need for production, but what is the best way. You can use dynamic disk properties to concatenate two partitions into one, but this isn't exactly the best for a production environment. There is a better way using the Diskpart utility, surprisingly from Microsoft. I wasn't too familiar with Diskpart until this past year. We've been looking at upgrade paths from WinXP to Win 7 and have started using the utility. We've avoided Vista like the plague.

     Diskpart is a newer utility from Microsoft that replaces the ancient Fdisk for creating and manipulating hard drive partitions. It's biggest strength is that it is free and that it brings more powerful / modern tools to the Windows world for disk partitioning.  

     As anyone that uses VMWare ESX knows it is really easy to add space to existing Virtual  Hard Drives. The difficult thing is utilizing the extra space in the Windows Server. The problem is compounded when using Templates in VMWare to deploy a server. You want the template to take up as little space as possible when in storage but need to expand that partition to an appropriate size in production. Window's native gui utility Disk Management doesn't have the ability to "Expand" disk partitions (Windows Server 2003). Diskpart though allows you to do that rather easily albeit with a few exceptions but I'll show you how to get around those exceptions as well. 

     As usual all of these steps have been tested successfully in my Test Lab. I am not responsible for any problems that you may encounter. I would also recommend that you only do this on a new Server Template deployment and not a live production system. If you must do this to a live server make sure you "Clone" your server before you begin so you have a backup you can recover from should something go wrong. That being said, if you follow these steps closely you should have no problems.

     First Deploy your server within VMWare's VCenter. Once it's established go in to "Edit Settings" of the Virtual Machine.

     After clicking "Edit Settings" you will see the properties for the Virtual Machine as below:

Highlight Hard Disk 1 and under "Disk Provisioning" increase the provisioned size to whatever you need for production. In this case we'll increase it to 150GB.

     As you can see above the Size has been increased to 150GB. All of this can be done while the Windows Server is on. Hopefully you noticed in the screenshots above there is only 1 Virtual Hard Disk installed in this server. It must therefore be the C: partition of Windows. As I said above there is a catch with DiskPart and the Boot Volume in Windows Server 2003. You cannot "Expand" the partition on the Boot Volume, sort of. It is more precise to say that you cannot "Expand" the Boot Volume while it is Active. The way around this is to attach the Virtual Hard Disk as a second Volume on another server. In this way the Disk you want to "Expand" is not Active. 

     The first thing you need to do is "Shutdown" the server that you want to expand the partition on. Once it's turned off go to the "Edit Settings" of another Virtual Machine that is active.

As highlighted above Click on the "Add" button.

Highlight "Hard Disk" and select the "Next" button.
Choose to "Use an Existing Virtual Disk" as shown above and click on "Next".
We now need to browse to the Virtual Hard Disk File that we want to Expand. Be careful here, you want to make sure that you select the correct disk file for the correct server.

After Clicking the "Browse" button you'll be taken to a listing of your DataStores. Select the DataStore that contains the Virtual Machine with the Hard Drive that you want to expand.
Find the folder containing the files for your Virtual Machine that you want to expand. Select the Hard Drive file and click Ok. The file will have a .vmdk extension.
Once selected VMWare will give the hard drive the next Available Virtual Device Node. Nothing further needs to be done with this screen. Click Next.
The final summary screen will be shown as above. Click Finish to complete adding the Virtual Hard Disk to the server.

     This attaches our 150GB Virtual Hard Drive to the live Windows Server. We now need to go into Windows by opening a Console session to the Server. Once on the Windows 2003 server Open the Computer Management Interface and Highlight Disk Management.
     With Disk Management Highlighted you should see all of the Virtual Hard Drives attached. If you don't see the second Hard Drive right away, Right Click Disk Management in the Left Window and Select "Rescan..." from the popup menu. This should make the second Hard Drive appear in the Window as shown above. You can see the Boot Volume of this server above shown as Disk 0. The Disk we want to expand is shown as Disk 1. You can also see that the 1st partition on that drive is the original 128GB and there is an additional space after that shown as "Unallocated". That is the additional space that we added through VMWare.

     Now we need to open a Command Prompt in Windows. At the command line type "diskpart" and press enter.

Next type "list volume" to see the listing of Hard Disks that are detected by "DiskPart". You can easily identify below the difference between the Boot Volume and Expansion Volume by examining the Sizes.
Next type "select volume 1" and press enter.
Now type "extend" at the command line and hit enter. 
     As you can see above the expansion of the existing partition was successful. You can also see the confirmation of the new size in Disk Management. It now shows 150GB for the full size. Finally type "exit" to close out DiskPart.

     Now we need to clean things up. Go back in to "Edit Settings" of the current Virtual Machine. We need to remove the second drive that we expanded from this machine.
Highlight the second drive, in this case Hard Disk 2 and click the "Remove" button. Make sure that you also select "Remove from virtual machine". We don't want to remove and delete the files, we still need those for the original Virtual Machine. Click Ok to remove the drive.

     Since we didn't remove this drive from the original Virtual Machine it is ready to go. Power on the Virtual Machine and log into Windows when ready. You will get the following prompt. Click "Yes" to reboot and finalize the detected changes.
     After rebooting log back in and open Computer Management, then highlight Disk Management.
     You'll now see that your boot volume C: has been expanded to 150GB and works just fine. If you need to expand a secondary drive attached to the same server it's even easier. Just do the DiskPart instructions again. Make sure to apply all the steps to the drive you want to expand. There is no need to attach the drive to another host virtual machine since it isn't the boot volume. In Windows Server 2008 it gets even easier. Back another time with much briefer instructions on that. 

     As always I hope you found this useful. If you did let me know, leave a comment.