Blog: Windows 2008 Server

A coworker and I ran up against a very interesting situation at a virtualization consulting customer's site the other day. We got an after-hours call from the customer that said he was working on the console of a new Windows 2008 virtual machine. He was trying to set the IP address on the NIC and accidentally choose the “bridge network adapters” setting. Afterwards, he was unable to get to anything in the internal network from this server and several other VMs could not communicate with the internal network either. My coworker connected via VPN just fine, but was unable to ping the vmhost2. He could ping the SBS server, one terminal server, and the ISA server. We discussed over the phone that the particular ESX server that those servers were on must have somehow gotten isolated from the network. Sure enough, when my coworker checked the NIC status on vmhost1, it showed that all NICs connected to the LAN network were disconnected. We decided to go onsite and check out what was going on. On the way out, I realized what had happened. When the two NICs got bridged on that VM, it created a loop and must have looped a BPDU and err-disabled the port. Once onsite we confirmed that the port was down and portfast was NOT enabled on that port.

So, the warning here is two fold…yes, a VM can take down the whole ESX server. And second, its best to turn on portfast for ports connected to ESX servers. They don’t understand STP anyway.

In IIS6 you allowed large file uploads to an ASP.NET website by adding the following key to the web.config:

<httpRuntime maxRequestLength="102400"
     useFullyQualifiedRedirectUrl="true"
     executionTimeout="900" />

You would just set the maxRequestLength to a number of kilobytes that is greater than the size of the largest file you plan to upload.  We recently moved a site from a server running IIS6 to IIS7.  After the move, when our website users were having problems uploading large files.  They would submit a form, the progress bar would move for a while, then they would get a 404 page not found error.  The form was posting back to itself, so the page did exists.  Turns out we needed to add an additional web.config setting that’s new to IIS7. [more]

    <system.webServer>
        <security>
            <requestFiltering>
                <requestLimits maxAllowedContentLength=" 104857600"/>
            </requestFiltering>
        </security>
    </system.webServer>

The maxAllowedContentLength in this settings is specified in bytes.

Note: These settings exist to help revent denial of service attacks, so keep that in mind when you pick your limits.

Small Business Server 2008 has several "Connect to the Internet" wizards under Getting Started Tasks in the SBS Console.  Depending on your order of setup, running the "Set up your Internet Address" task may activate DHCP without telling you it is doing so.  A key problem here is that, when activating it, a scope is auto-created which includes the entire subnet on which the SBS server sits.  The only exclusions auto-created might be the SBS address and that of the SBS’ gateway.  This could occur on a production subnet and cause IP-address conflicts with other live devices if not noticed quickly.

I have a few notes to share on DFS in Windows 2008 R2. First of all, Microsoft changed the way DFS replication is done starting in Windows 2003 R2. In previous versions, DFS replication for SYSVOL shares on domain controllers as well as DFS replications was handled by FRS (File Replication Service). Starting in Windows 2003 R2, the service was overhauled along with the management interface. Replication for DFS is now handled by DFS Replication Service and the two (DFSR and FRS) don’t play ball with one another. That is to say that you can’t use pre-windows 2003 R2 servers in the same DFS replication topologies with post-windows 2003 R2 servers. However, SYSVOL in all versions continues to use FRS until all domain controllers are Windows 2008. Additionally, once you have your DFS tree in place and get your replication topology set up, you’re not done. Make sure to edit the file exclusions list for the replication group. By default, a new replication group EXCLUDES files with the ~ (to start the file), .tmp, and .bak files. The ~ makes sense, but .tmp and .bak could be  a problem depending on the type of data in the share.

At a client site, I have been testing some automated ways to move users from v1 to v2 profiles. All their users are on Windows XP and we are moving them to Windows 7. I was looking specifically for a graceful way to allow interoperability between the profile versions and keep us from having to touch every user profile to copy over data. What I found was a little annoying. There is really only two ways to migrate data from v1 to v2 profiles.

1. Use Folder redirection to share data between the profile versions by redirecting relevant data to a network share that can be used by both profiles.
2. Use the user state migration tool [more]

If you are NOT using roaming profiles, the USMT is the best way. If you are using roaming profiles, the folder redirection is the best way. The gotcha here is to make sure you create the folder redirection policy FIRST on a Windows Vista, 7, or 2008 system BEFORE editing it on a Windows XP or 2003 system. There is something about the way the GPO is created/built that will not allow it to apply to vista, 7 , and 2008 systems if it is created with XP or 2003 first.

I was trying to connect a VPN from Terminal Server that was recently upgraded to Windows 2008 and when I would connect, I would lose my terminal server connection completely.  I would then have to log my session from a different server using Terminal Services Manager.  I tested the same VPN connection on a local Windows 7 machine and experienced similar issues where all of my network connections were dropped upon connection. 

Upon examining the properties of the VPN connection entry, there was a checked setting to use the default gateway on the remote network.  Unchecking this box through the IPv4 properties stopped the disconnects from happening.  I also recommend unchecking the use of IPv6; it also has the same options to use the remote network’s gateway.  [more]

I was working on moving a group of users to a new Windows Server 2008 domain. I had copied all the users profiles to the new server. Whenever I tried logging in with a roaming profile, on a Windows XP client, it would get an error and load a local default profile. I found that when using Windows XP clients on a  2008 domain, roaming profiles will not recognize the presents of a version 1 profile (Windows XP, 2000, 2003) without the presents of a version 2 (Windows Vista, 7, 2008) user profile. In order to resolve the issue I logged onto the domain controller  as one of the users which initiated the creation of a version 2 profile for that user. I then modified the permissions and use it as a default profile and copied it to all the other users profile folders. This meant that all user then had a “NTProfile” and “NTProfile.V2” folder in the profile path. I then logged into a Windows XP client and it loaded the version 1 profile without  any problems.

A while back I mentioned that you can just enter sendto in the start/run field and it would open your sendto folder.  There are many of these shell folders – special folders that may be on disk, or may be fabricated by the OS.  The “correct” way to reference these is with the “shell:” prefix.  So you can specify shell:sendto, shell:startup, shell:favorites, etc. [more]

The full list is in your registry at

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions

Note: The name in the registry does not always match the name you see in explorer.

I had been troubleshooting a DL380 server and replaced bad memory.  I had the server powered off and connected to it using iLO.  I used iLO to send power signal to the server so that I could watch it boot up.  For some reason right after I powered on the server, I lost connectivity to iLO and the blue UID light on the server remained on.

Once Windows came up, I checked the HP System Management software, and it did not list an iLO management processor like the other servers did.  I figured that iLO was hung, so I shutdown the server.  Still no response from iLO, so I checked BIOS with a physical monitor and keyboard.  Upon boot, it did not show the message to press a function key to configure iLO.[more]

In order to reset iLO, I had to completely unplug both power supplies from the back of the server.  After powering the system on again, I then saw the option to configure iLO.  I saw that it had an IP address but I still could not connect.  The blue UID light was off though.  After the system came back up, I had to reset the iLO interface through the HP System Management software before it would work again correctly.