Alberto Ortega’s Blog

This is a common problem IT Administrators face when a member Server/Workstation reaches it’s Domain Controller only via a VPN connection. We need the VPN connection to be established before the logon time, so the member Server can Authenticate agains it’s Domain Controller, otherwise (unless be have cached credentials) we’ll get a “No Domain Controller Could Be Contacted” error message.

Here I present a solution I’ve used on a Windows 2003 member server. These steps are easily extended to accomplish the same task on a Windows 2000/XP system.

Step 1: Create a command-line that establishes de VPN connection
I’m assuming that you have already created the VPN connection and it’s working properly if you dial it up manually. So we will get focused only on it’s automation.

We will use the Rasdial command to accomplish this first step. You should test the following command on a Command Line window and test if you can successfully establish the VPN connection:

rasdial ConnectionName Domain\VPNUser Password

For example:
rasdial Southworks-HQ EXTRANET\beto p@ssw0rd

If running that command line success, then you can move forward t the next step.

Step 2: Wrap the Command-Line as a Service
The best approach when trying to do any task before logon time always is trying to use a Windows Service. You can Wrap any command line as a Windows Service using the XYNTService tool provided by The Code Project.

Once you have downloaded the GUI program to configure XYNTService, use it to wrap your Command Line created on Step 1 as a Windows Service. You should get to something like this:

When you click the Install button your service will be listed as any other service on the Services Snap-In.

Now go on and do a little Test. When you start your service (from Services Snap-In) the VPN connection should be established.

Note: Take care that the account under the service is running is Local System and depending on your configuration this account may not have sufficient rights to establish the VPN connection, you should consider running the service under another account with higher privileges. And, of course, check that your service is configured for Automatic Startup.

Step 3: Setting service Dependencies
We already have our service created, now we need it to start at the proper time when Windows starts.

Q: How can you control the startup time of any Windows Service?
A: Adding a dependency.

For our service it’s enough if we guarantee that it will start after the LanmanWorkstation Windows Service, so we can ensure that we have network connectivity and the NetLogon service has not yet started.

Adding a dependency is just creating a registry Multi-String value in the proper registry key. So, open Regedit and find the registry key that holds your Service configuration, that should be located on:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<<ServiceName>>

Under that key, create a Multi-String value named “DependOnService” edit the value adding the String “LanmanWorkstation” that will create a dependency for your service on the LanmanWorkstation service.

That’s all, restart your computer and your VPNDialService will Dial the VPN connection before logon time, so now you can login using a domain account.

Hope that helps!!

I’ve get used to the GPMC (Group Policy Management Console) tool for managing group policies and delegate group policy privileges, by the way if you still use the Active Directory Users and Computers to administer Group Policy, I strongly encourage you to go to Microsoft’s Web site and download GPMC.  (www.microsoft.com/windowsserver2003/gpmc/).

The only negative to using the GPMC is that you must install it and run it on a Windows XP or Windows Server 2003 computer, but believe me that it’s worth the effort.

Well, I’m not going to talk about the GPMC, there are many resources on the web to learn what is it about. This post reefers to an issue when you try to edit a group policy by right-clicking on a policy an select the Edit option on the GPMC, if you try this on a Windows 2003 x64 server you will get the following error:
—————————
gpedit.msc
—————————
Windows cannot find ‘gpedit.msc’. Make sure you typed the name correctly, and then try again. To search for a file, click the Start button, and then click Search.
Digging through different newsgroups, I’ve found what is happening behind the scenes here.
This has to do with 32bit and 64-bit snap-ins, 32-bit and 64-bit MMC.exe, and 32-bit and 64-bit hosted snap-ins.

• MMC can be 32-bit or 64-bit. MMC.exe

• Snap-ins can be 32-bit or 64-bit. *.msc

• A snap-in can host other snap-ins (take computer management for example, it hosts a number of different snap-ins).

The explanation was taken from (http://support.microsoft.com/?id=304718)

Windows Server 2003 Administration Tools issues on x64-based  versions of Windows Server 2003:
When you try to modify a GPO from the GPMC, a call is made to start the Gpedit.msc file. Currently, the snap-ins that call the Gpedit.msc file are 32-bit tools.  However, on x64-based versions of Windows Server 2003, Gpedit.msc is a 64-bit snap-in.
This problem will be corrected in a future release of a 64-bit Adminpak.msi package.
To work around this problem, use either of the following methods.

Method one
Modify the GPOs from a computer that is running a 32-bit version of Windows Server 2003, a 32-bit version of  Windows XP, or a version of Windows 2000.

Method two
Use the following commands to start the snap-ins, and then modify the GPOs:
- To start the Active Directory Users and Computers snap-in:
        %windir%\syswow64\mmc.exe %windir%\system32\dsa.msc -32
- To start the Active Directory Sites and Service snap-in:
        %windir%\syswow64\mmc.exe %windir%\system32\dssite.msc -32
- To start the Group Policy Management Console snap-in:
        %windir%\syswow64\mmc.exe %windir%\system32\gpmc.msc -32

I’ve been running Windows 2003 Server Enterprise x64 for a while now, on a lab environment, in order to get familiar with common issues
before we deploy it as a production server. This post is aimed to share
the gained knowledge on this experience.

My experiences lies on an Intel EM64T architecture, with 1GB Memory and 3.0 Ghz CPU. When planning to deploy a Windows 2003 Server x64 OS first take a look at the hardware requirements:

A key feature of the 64-bit extended architecture is the capability to
run both 32-bit and 64-bit applications. The architecture defines
"Operating Modes" wich allows x64 enabled OS to run existing 32-bit
applications natively on a 64-bit processor without recompilation. The
capability to run 32-bit applications natively on the 64-bit processor
is a distinguishing feature of x64, and is possible because the x64
instruction set is an extension of the industry-standard x86
architecture. At first glance this sound great, you shouldn’t have any
problem using your actual 32bit  applications on this new server,
but there are some things to be aware.

First, drivers, Windows Server 2003 x64 Editions
require all drivers (including all device drivers) to be 64-bit
drivers. All 32-bit kernel-mode drivers must be ported to 64-bit. So,
every specific vendor must provide a 64-bit driver for each device that
Windows Server 2003 does not provide  it’s driver. In my case I
could’n get any driver for a network printer (HP Laserjet).

Second, virtual server, Virtual Server 2005 requires a 32-bit host operating system. Virtual
Server 2005 will run on x64-based hardware provided it is running a
32-bit version of a supported host operating system. Virtual Server
2005 R2 runs on both 32-bit and 64-bit (x64) host operating systems.
Virtual Server 2005 R2 supports AMD64 and Intel IA-32e/EM64T (x64)
processors. Note that Virtual Server 2005 R2 does not support Itanium
(IA-64) processors.

At the time of this writing, Virtual Server
2005 R2, is on Beta stage, so you can get it for free, for trial and testing purposes if you sign in, on the Microsoft Beta Place.

I had no problem using the Virtual Server 2005 R2, hosting many servers as we do on a production environment.

My advice, if you have bought an Intel EM64T procesor and you are
wondering whether to give a chance to Windows 2003 Server x64, go
ahead, just be aware of what we talked on this post and nothing
unexpected should happen to you.

On the other hand plan carefully and investigate the compability
between each Microsoft Server Solution (MS Exchange, ISA Server, WSS,
etc) that you want to deploy on the x64 platform. For instance, there
is a known issue between Windows 2003 Server x64 and WSS.

Related Links:

http://www.dell.com/downloads/global/power/ps2q05-20050116-Purush.pdf (Dell’s Deployment Guide)

http://www.dell.com/downloads/global/power/ps2q05-20050148-Purush.pdf (Dell’s Platform Overview)