When installing a new Windows 2008 server or upgrading an existing server to Windows 2008, the Computer Browser service is set to disabled by default.
If you upgrade the Domain Controller that is assigned the PDC FSMO role or you move that role to a Windows 2008 DC, you may see the domain wide NetBIOS-based network browse list get smaller and remote subnet machines will disappear from the list. Eventually you may only see computers from the local subnet in the network browse list. If you have subnets with only one server and it is Windows 2008, then you may also see inconsistent local subnet browse lists due to clients taking a master browser role and they may be rebooted, turned off, etc.
You may see a combination of all local computers on a subnet and some remote computers on a subnet if you have IPv6 deployed and LLTD is being used with Network Discovery to build a network browse list, using Vista clients and Windows 2008 servers. To see if that is the case, you can use the "net view" command or the browstat.exe tool to see just the NetBIOS-based browse list.
To resolve this problem, you can either set the Computer Browser service to Automatic on the DC holding the PDC role, or move the PDC role to another DC that has the Computer Browser service started. You will need File and Printer sharing On in the Network and Sharing Center, otherwise the Computer Browser service will fail to start since the required ports will not be open. In a multiple subnet environment, make sure WINS is configured properly so that you have the proper NetBIOS name resolution. After making the corrections, the computers holding the master browser roles will begin to populate the browse list for the entire network.
If you need a tool to test and determine the browsing roles from a Windows Server 2008 machine, you can use the Windows XP Support Tool Browstat.exe on a Windows Server 2008 to determine the computer that has the browse master roles. The Windows XP Service Pack 2 Support Tools can be downloaded from Microsoft at the link listed below and installed on a XP machine. After that, move the browstat.exe utility to the Windows Server 2008 machine to do the test.
Windows XP Service Pack 2 Support Tools
- Tod Edwards
This post is second in a series by David Pracht and Steve Martin. To read the first post, click here.
Developing a plan...
We started by brainstorming about what we might need to consider in the environment.
For example – Does the Forest or Domain level matter? What exceptions will we need? Do we need to consider what OS we configure polices from? What machines will we need?
Our first consideration was how to implement the environment. We decided to implement the simplest possible configuration that a novice user might envision - Domain Isolation using the Microsoft Default policies that look, from their descriptions, like they should work without much modification. So for example, the servers and clients in the Secure network would need to have an IPsec policy of Secure Server - Require Security. The Servers and clients in the Boundary network would need to have an IPsec policy of Server - Request Security, and the DC’s and the untrusted servers and clients would need to have an IPsec policy of Client – Respond Only.
Last, all these settings would most likely be set via Group Policy from the DC.
Figure: Basic IPsec Domain Isolation scenario
Along the way the following questions arose.
Q: Does the Forest Level affect IPSec?
A: No the Forest Level does not affect IPSec even when using AuthIP with Windows Server 2008 and Vista as there are no schema extensions.
Q: Does the Domain level affect IPsec?
A: IPSec is not affected by the Domain Level but a 2008 domain level will require all 2008 Domain Controllers. This is not a likely scenario as most people will need to do a migration for Windows Server 2003 and not be able to use a 2008 Domain Level yet.
Q: What do we need to consider concerning Group Policy Management?
A: Group Policy management does have one caveat. Group Policy only requires that the policy be configured from a Windows Vista or Windows Server 2008 machine if you need support for the new features provided with AuthIP.
Our plan is a Windows Server 2003 Domain with 2003 Forest and Domain levels using XP/Windows Server 2003 IPsec policed managed from the DC.
The following machines are used with this plan:
2003 Domain Controller as untrusted 2008 Domain Controller as untrusted 2003 Member Server in the Secure domain 2003 Member Server in the Boundary domain XP client in the Secure domain
After implementing the above “All Default” plan we experienced the following. Servers and clients in the Secure zone could not communicate with any other machines. This means that they could not: Resolve names via DNS Obtain an IP address from DHCP Request Kerberos tickets for authentication or much of anything else except ICMP
Have we forgotten something? Maybe we need this hotfix:
914841 How to simplify the creation and maintenance of Internet Protocol (IPsec) security filters in Windows Server 2003 and Windows XP
The Windows Server 2003 update and the Windows XP hotfix add functionality to Windows that enables you to use an IPsec "Simple Policy." For most environments, the installation of this update and hotfix lets you reduce the number of IPsec filters that are required for a Server Isolation deployment or for a Domain Isolation deployment. You can reduce the number of IPsec filters from many hundreds of filters to only two filters.
We added the hotfix to make sure that the timing was correct for connections but still couldn't make any of the connections work even though it was supposed to allow a configuration with fewer (if any) filters/exceptions.
What was left out of the plan on purpose was something we felt like many customers might not plan for: Exceptions.
So why did our initial set up not work? There is a hint in the points above and we will let you in on the solution with our next post.
- David Pracht
- Steve Martin
954412 The IPsec remote management registry value is not preserved when you upgrade your computer to Windows Server 2008 or to a Server Core installation of Windows Server 2008
954408 Dynamic updates do not work on the standard primary DNS zone in Windows Server 2008
954396 The BITS client upload job fails when you use two virtual directories that share the same physical folder on a Windows Server 2008-based computer
954395 An additional cleanup task remains after you upgrade a server that is running BITS from Windows Server 2003 to Windows Server 2008
954423 A Windows Server 2008-based DNS server stops responding, and event ID 7023 is logged in the DNS server event log
- Mike Platts
In recent weeks we have seen a number of cases with intermittent file sharing connectivity to Windows Server 2008 servers. I wanted to get this information out so that people who may be experiencing the issue won't have to spend a lot of time tracking down the problem.
The issue generally manifests in one of two ways:
Network traces look similar in both cases. After the TCP 3-way handshake the client sends an SMB Negotiate Dialect but the server doesn't respond.
Eventually the TCP session times out and is reset as seen in this example:
Two things are currently known to address the issue:
Most of these cases involved older anti-virus software versions but we have also seen the issue with current versions that are supported on Windows Server 2008.
While there is not currently a complete resolution, I hope providing this information will help some people identify this issue quickly so they can resolve it and minimize the disruption to their environment.
We have been hearing of an issue since the recent release of an update to address a DNS spoofing vulnerability, MS08-037, discussed in KB951748. After application of the update, affected systems can experience problems with applications that rely on DNS name resolution. For example, a user on an affected system would not be able to browse the Internet.
The cases we have seen so far have involve ZoneAlarm software and Check Point Endpoint Security (previously named Check Point Integrity).
There are updates available for the ZoneAlarm products affected as well as interim workarounds posted at the following link at the ZoneAlarm site:
Workaround to Sudden Loss of Internet Access Problem
Check Point has updates available for its Endpoint Security and Integrity products as well. These updates and additional information may be found at this link:
Installing Microsoft security update for Windows (KB951748) might prevent Secure Access, Endpoint Security (Integrity) and ZoneAlarm users from accessing the Internet
We recommend updating the Check Point or ZoneAlarm software to correct the problem. We do not recommend not installing or uninstalling the update described in security bulletin MS08-037. Please read the bulletin to learn more about this vulnerability:
Microsoft Security Bulletin MS08-037 - Important
More information about the vulnerabilities corrected in this update may be found here:
CVE-2008-1447
CVE-2008-1454
Security Vulnerability Research & Defense - MS-08-037: More entropy for the DNS resolver
953730 The netsh command cannot start the PNRP Machine Name Publication Service on a Windows Server 2008-based computer
952899 Event IDs 1018 and 1020 appear in the Application log after you remove the SNMP service on a Windows Server 2008-based computer
953828 The NLB host does not converge as expected on Windows Server 2008 Hyper-V virtual machines
954425 Error message when you use the Bitsadmin.exe tool to try to upload files to a Windows Server 2008-based server that is running Internet Information Services 7.0: "The requested URL does not exist on the server"
952131 Piggybacked data on a TCP Acknowledgement (ACK) package may bypass the WFP inspection process in Windows Vista
952709 A reliability and performance update is available for Windows Vista SP1-based computers
954370 Error message when you try to connect to a domain controller for remote administration from a Windows Vista SP1-based computer that has Remote Server Administration Tools (RSAT) installed: "The RPC server is unavailable"
953609 Error message when you try to add a wireless network to a Windows XP-based computer that has hotfix 917021 applied: "At least one of your changes was not applied successfully to the wireless configuration"