[Today's post comes to us courtesy of the Shawn Sullivan and Mark Stanfill]
A known issue exists in Vista and Windows Server 2008 where use of the netsh command to change global TCP/IP settings will cause invalid values to be written into the registry under ‘HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters’. An example of this behavior is found when you run “netsh in tcp set global autotuninglevel=disabled”. You will find the following highlighted values are configured incorrectly:
Invalid:
Meanwhile this same key from a default installation of SBS 2008 will look similar to this. Note: the only highlighted value that is configured by default is TcpTimedWaitDelay and it is set to 60:
Default:
We have seen send/receive issues with Outlook clients as a result of this. In this case, the Exchange BPA will issue a warning if the TcpTimedWaitDelay is anything other than 60:
Recovering from this problem is a two step process. First, to prevent the issue from reoccurring the next time you run netsh, install the hotfix from the following link. This hotfix is not included in Windows 2008/Vista SP2. It will not reverse incorrect values or make any changes to the key itself:
http://support.microsoft.com/kb/967224
You must then fix the invalid entries by restoring a backup of the ‘HKLM\System\CurrentControlSet\Services\Tcpip\Parameters’ key. If you do not have a backup, you can run the following powershell script to revert this key to a default configuration:
http://cid-d5fe25afb6c3615f.skydrive.live.com/self.aspx/.Public/NetshRegFix.ps1
Download this ps1 file to an easily accessible directory, such as c:\windows\temp. Open powershell as administrator and execute the script, substitute the path to the ps1 file as needed:
This script will make a backup of this key on your desktop in a folder called “TcpIpParametersBackup”, change TcpTimedWaitDelay to 60, and then delete the following values which will set them to their default configurations:
You will need to reboot the machine after running the script.
The following whitepaper lists the default settings, descriptions, and valid ranges of the configurable TCP/IP registry values in Windows 2008/Vista:
http://download.microsoft.com/download/c/2/6/c26893a6-46c7-4b5c-b287-830216597340/TCPIP_Reg.doc
Note: There are some registry values from Windows Server 2003, such as “EnableRSS” and “EnableTCPChimney”, which are no longer used in Windows Server 2008. These settings are now only configurable in the using the netsh utility and on the properties of network adapters that support them. The following KB gives some examples of netsh commands:
Information about the TCP Chimney Offload, Receive Side Scaling, and Network Direct Memory Access features in Windows Server 2008
http://support.microsoft.com/kb/951037
Automating these settings
If you wish to automate disabling these settings for your SBS installations, they can easily be set using a combination of reg.exe and netsh. For example:
netsh int tcp set global rss=disablednetsh int tcp set global chimney=disabled Reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v EnableTcpa /t REG_DWORD /d 0 /fReg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v NetDMA /t REG_DWORD /d 0 /f
[Today's post comes to us courtesy of the SBS Team]
Last Monday Microsoft launched a new pilot program in our Advisory Services space. Advisory Services is a consultative support option that provides support beyond standard break-fix issues. The new program involves remote, phone-based support for issues such as product migration, code review or new program development. The service is intended for Developers and IT Professionals for shorter engagements that don’t require traditional onsite consulting or sustained account management services available via other Microsoft support options.
For the Application Compatibility engagements, we’ll start off with some basic scoping questions such as whether the application is 16-, 32-, or 64-bit. Is it a client-server application? What compatibility issues are you experiencing? Slow Performance? Hang or Crash? Installation problems? The support engineers will be using tools such as the Application Compatibility Toolkit, the the Standard User Analyzer Wizard, and the Setup Analysis Tool.
There’s much more to the program than we can do justice to in a blog post. The KB Article referenced below has more details about the program and how to engage us. So, if you’re working on a pesky Windows Vista or Windows 7 Application Compatibility issue, give us a call – we can help!
Additional Resources:
[Today's post comes to us courtesy of Wayne McIntyre]
Microsoft Exchange Sp2 has been released, however there are additional steps required to get it to install onto an SBS server. Please review the following KB article for steps on installing Exchange 2007 Service Pack 2 on SBS.
http://support.microsoft.com/default.aspx?scid=kb;EN-US;973862
Updated: 08/26/09 – Removed KB text and added link to KB article.
On August 25th, Internet Explorer (IE) 8 will be offered through WSUS as an Update Rollup. On default installations of SBS, this will not be automatically approved for installation. You will need to manually approve it in the SBS Console or the WSUS Console. However, if you are automatically approving Update Rollups by manually configuring WSUS, then it is important for you to know that the IE 8 Installation Blocker Tool used to block Automatic Update deployments to your machines will not block WSUS deployments of IE 8. For more information regarding this, please see the IE 8 Blocker Toolkit FAQ:
http://technet.microsoft.com/en-us/updatemanagement/dd365124.aspx
Once the update is approved for deployment to your chosen machines in WSUS, the users will be taken through a brief IE 8 setup while installing the latest round of updates.
Under certain circumstances, you might be unable to manage DHCP and get a screen like the one shown below.
Among a number of causes, this could be the result of having a record for the servers IP address in your hosts file which resolves to a name that does not exist in Active Directory. Since DHCP does a reverse lookup on the binding IP (your internal server’s IP) to discover the computer object in AD to authorize it for DHCP services, a return of an invalid hostname will cause the authorization to fail. You can verify this as well by performing a ping test as follows to verify the bad resolution of the servers IP to its name. On this example, we will assume that the server’s internal IP is 192.168.16.2 and the server name is SERVER.CONTOSO.LOCAL.
C:\Windows\System32\drivers\etc>ping -a 192.168.16.2
Pinging badhosts.record.com [192.168.16.2] with 32 bytes of data:
As you can see from the output, the reverse name resolution for the server’s IP does not match the server’s name and thus won’t match the AD object.
Resolution:
To resolve this simply delete the record out of your hosts file which is found in %windir%\system32\drivers\etc.
The default hosts file would look like this:
# Copyright (c) 1993-2006 Microsoft Corp. # # This is a sample HOSTS file used by Microsoft TCP/IP for Windows. # # This file contains the mappings of IP addresses to host names. Each # entry should be kept on an individual line. The IP address should # be placed in the first column followed by the corresponding host name. # The IP address and the host name should be separated by at least one # space. # # Additionally, comments (such as these) may be inserted on individual # lines or following the machine name denoted by a '#' symbol. # # For example: # # 102.54.94.97 rhino.acme.com # source server # 38.25.63.10 x.acme.com # x client host
127.0.0.1 localhost ::1 localhost
If you need to create an alternate record for your servers local IP, we recommend that you first read on how SBS 2008 automatically creates DNS records for internal name resolution using your external namespace when you run the Internet Address Management Wizard as this most likely will cover most of the scenarios. Furthermore, you can also access an SBS 2008 server using the host name “sites” (I.E.: \\sites or https://sites)
For more information on the IAMW and how it configures the SBS server, please check the following links:
http://blogs.technet.com/sbs/archive/2009/03/09/sbs-2008-iamw-internet-address-management-wizard-screencast.aspx
http://blogs.technet.com/sbs/archive/2008/10/15/introducing-the-internet-address-management-wizard-part-1-of-3.aspx
http://blogs.technet.com/sbs/archive/2008/10/16/introducing-the-internet-address-management-wizard-part-2-of-3.aspx
http://blogs.technet.com/sbs/archive/2008/10/17/introducing-the-internet-address-management-wizard-part-3-of-3.aspx
[Today's post comes to us courtesy of Damian Leibaschoff and Chris Puckett]
The following post has been updated, please review the new RESOLUTION section:
http://blogs.technet.com/sbs/archive/2009/05/28/sbs-2008-fax-routing-to-email-fails-with-the-following-error-occurred-0x80040211.aspx
If you have previously contacted support and implemented the temporary workaround you can remove the scheduled task that was added by the support engineer upon installing this fix. For this, follow these steps: