Author: Christoffer Andersson

Posted on

Windows Server 2003 Domain Controllers may perform Automatic Site Coverage for RODCs

Note: Domain controllers running Windows Server 2003 do not consider RODCs when they evaluate site coverage requirements and may register its Domain Name System (DNS) service (SRV) resource records for a site that contains an RODC. As a result, they perform automatic site coverage for any site regardless of the presence of an RODC for the same domain. Consequently, client computers that attempt to discover a domain controller in the RODC site can also find the domain controller that is running Windows Server 2003 and may not authenticate to the RODC.

 

There are a few possible solutions for this problem:

 

 

    1. Apply the Windows Server 2008 read-only domain controller compatibility pack for Windows Server 2003 clients and for Windows XP clients (http://support.microsoft.com/kb/944043/en-us)
      (This hotfix has to be applied to all Windows Server 2003 DCs that may perform automatic site Coverage)

 

    1. Ensure that only domain controllers running Windows Server 2008 are present in the site closest to the RODC site.

 

    1. Configure the weight or the priority of the DNS SRV records so that clients are more likely to authenticate with the RODC than with a remote Windows Server 2003 domain controller.

 

  1. Disable automatic site coverage on domain controllers running Windows Server 2003 present in the site closest to the RODC site.

 

How to disable automatic site coverage:

 

 

    1. Click Start, click Run, type regedit, and then click OK.

 

    1. Navigate to the following registry subkey HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetlogonParameters

 

    1. Click Edit, point to New, and then click DWORD Value.

 

    1. Type AutoSiteCoverage as the name of the new entry, and then press ENTER.

 

    1. Double-click the new AutoSiteCoverage registry entry

 

    1. Under Value data, type 0 to disable automatic site coverage. 1 = to enable it.

 

    1. Click Start, Click Run, type cmd and then click OK.

 

  1. In the Command Prompt, type the following command:
    nltest /dsregdns or restart the netlogon service
Posted on

Back in Sweden after a month in US

I’m back on track in Sweden after being in the US for about a month; actually I have been working a month here already, so we continue the “Windows Vista Enterprise Project” that I’m currently completely busy with (see previous post). There still remains very much work to do, and trying to catch up with all different kind of dependences this project has to other teams inside the company i.e. DNS Team, Active Directory Team, PKI Team, Storage Team, Network Team, etc takes a lot of time.

 

 

Yesterday we did ship a first release of our Windows Vista image supporting 5 different hardware models, both x86 and x64 (that actually makes it 10) and a customized installation of Microsoft Office 2007. To certify a specific hardware model, takes about 8 hours (both x86 and x64) and then we use an ‘own’ developed method for certify our hardware. This is basically it (a bit simplified)

 

 

    • Download all drivers for the specific model from the hardware vendor’s web site.

 

    • Create a folder structure for the specific hardware model in the central storage repository that looks something like:
      • HP nc6010p x64
          • 6010p
              • Network
              • Chipset
              • Storage
            • And so on…
        • Swsetup
            • App0Driver1
          • And so on.

 

    • Extract the content by lunching a custom tool (wrapping around winrar.exe)
      • Identify driver type. (Core Driver) or (App0): The difference between those is that Core Driver is a REAL driver and App0 is a “BAD” driver that needs to execute some kind of setup package, i.e. .exe or .msi package.

 

    • Check in the “REAL” drivers into the System Center Configuration Manager (Our main deployment tool) into the “All Drivers” driver package.

 

    • Create Application Packages for all App0 Drivers.

 

    • Create a task sequencer for the specific hardware, It will be something like “Install Vista Core-VBL-Hardware-HP6910p X86” The HW model is automatically detected by using a simple WMI query.

 

    • Adding the App0 packages, and configures the task sequencer to use “Auto Apply Drivers” that means that Windows Vista during the deployment will do a PNP detection and by its own chose the best drivers from the “All-Drivers” driver package. We have to watch out for compatibility issues here between x86/x64 and storage drivers, It can cause Windows to never boot.

 

    • Once the computer has finished it’s deployment, We use a custom made report in System Center Configuration Manager that tells us the best matching drivers that was picked up by Windows during the install, the best matching drivers in the “All-Drivers” driver package, as well all drivers that for some reason failed to install (if any) or if a device is completely missing a driver.

 

    • Based on this information, the drivers for the specific model is locked and the model us getting its own Driver Package, based on the report generated above, the deployment starts all over again but now with its own driver package instead of “Auto Apply Drivers”,

 

  • The process is repeated until all devices have a working driver.