Adding a workstation remotely to a domain (Win SBS 2003, Active Directory)

The only way I can think of doing this, and I am not sure if this appears when your in a workgroup, but try this...

Set up the VPN connection
Then when you get to the CTRL-ALT-DEL screen (if you are getting to the XP welcome screen you will have to hit CTRL-ALT-DEL twice)

When presented with the username/password screen, see if there is an option to "logon using a dial up connection" and check it.
Select the PPTP VPN connection
and Logon, then try adding the workstation to the domain how you normally would!

Bill

Interesting suggestion, Bill. I remember I saw this 'logon using dial up connection' on some PCs.
I tried it on my own (home) PC, but there I can't see this 'logon...' message, probably because I don't have a modem installed. Also after installing a fake dial up connection (with no modem) the 'dial up connection' option did not show at windows login. The PC I have to add to our domain (in fact it will be several PCs in different towns) have no modem neither.

Before being able to start the VPN connection I have to have a network (internet) connection - and obviously all this would have to happen before windows login if your suggestion should work.

Daniel

yes you would have to have a network/internet connection for this to work.

Once you put your login information in, check that box, and hit ok you will be presented with either the typical VPN connection screen... If you havent save the username/password or it will connect.

Bill

I checked on one of the PCs I have to connect to the domain: it does not have the "logon using a dial up connection" option at windows login. How can I make this option available?

Daniel

Hi J

I think this is a promising idea. I'll go and give it a try. It will probably take several days until I can report whether or not your approach worked for me.
Have you tried that yourself, once ?

Daniel

Yes loads of times.  If you have a remote system and need a new user to log in, but the VPN only loads once they log in, their AD logon account cant be verified until the VPN is loaded, but the VPN cant load till they  log in.  This trick lets them in the first time and then from then on their cached credentials on the workstation let them log in in future.

J

Great! I'll try as soon as possible and give you my feedback.

Daniel

Daniel-h...

The http://<servername>/connectcomputer method for joining a workstation to an SBS domain is disabled over the VPN because of the problem with installing software automatically to client machines from the SBS.  There are some posted workarounds... but I would ask WHY you want to do it.

I've tried a number of times and have only found it to be an inconvenience more than anything.  The VPN connection or RWW is a much better way to connect smoothly.  If you want the machine to be part of the domain so you can manage it for him, just create a local user account on it for yourself and be sure to keep port 3389 open on his router.  You can also use the machine's local policies if you need GP's on it as well.

Jeff
TechSoEasy

Hi Jeff

Here comes the WHY :-)
Without being a member of the domain, it is (according to my limited knowledge) not possible to create a VPN connection with IPSec/L2TP, which is the most secure VPN connection. For IPSec/L2TP I need a computer certificate which to my knowledge I only get when the PC is a domain member. For security reasons it is mandatory for us to use IPSec/L2TP. Therefore I have to join the PCs to the domain.

I don't care for distributed Software from the SBS or any other server service. (Antivirus and other security means are dealt with locally for these external PCs). I only have to offer the possibility to work remotely and access important company documents and applications via the 'most secure' VPN possible.

So far I did not implement Remote Web Workplace (RWW), only Outlook Web Access (OWA). But we have so many issues with OWA, that we are not tempted to even try RWW. I recently upgraded our server to SBS 2003 SP1 which should give more stable OWA and less bugs, but we are going to test that first.

Thanks for your thoughts,

Daniel

Thanks Jeff for your input. I'll check your link during the next few days and post my feedback.
Most of our OWA problems are language related: our users use German language versions. Sadly enough Microsoft has rather often problems with German and/or French umlauts, i.e. those characters that are not part of the English language.

Daniel

Here comes my feedback:

@J
I followed your instructions and managed to join a PC from a remote location to my domain. (Note for those trying the same: During the joining process I had to add the domainname.LOCAL extension in my case, otherwise I got a DNS error.)

@Jeff
So I joined the PC to the domain as described above, but still can not do a L2TP/IPSec VPN connection, probably because although the PC is a member of the domain now, the computer certificate was not transferred. May be because it is a "local" domain??
I checked the step-by-step document you recommended. (It is a hefty 70 pages doc.) I feel I have to invest more time in studying this and the related documents and to do some experimenting. I think this will then be a general solution for my problem.

@Bill
As soon as I had joined the PC to the domain, I got the "logon using a dial up connection" option on the logon screen, but it was not there before, when the PC was member of just a workgroup.

I would like to thank all of you for your input and would like to close this question now by splitting the points between J and Jeff for providing two valid solution paths. If I'll still have problems building this L2TP/IPSec connection, I'll post another question.

Daniel

If the certificate was created correctly with the CEICW (configure email and internet connection wizard) then it will have all domain names listed, so it isn't an issue with you having a .local domain name... in fact that's the recommended configuration.

These should be listed in the certificate's details display under issuer:

CN = server.network.com
CN = companyweb
CN = server
CN = localhost
CN = server.network.local

And, just fyi, if you're having OWA issues with the German version, you may want to post your problem to this newsgroup:  http://support.microsoft.com/newsgroups/newsReader.aspx?lang=de&cr=DE&dg=microsoft.public.de.windows.server.sbs

Jeff
TechSoEasy

Jeff, thanks for your hints. I'll continue to work on the certificate issues this week. I am having no problems with certificates and VPN via L2TP/IPSec for workstations that have originally been set up *inside* the company network/domain (and not from a remote location). Therefore I guess the certificates are set up correctly. But I'll check again.

I had posted my problems to the indicated newsgroup about a year ago, when we evaluated whether or not to use OWA. But unfortunately I got no answers. I just found a French or Belgian admin with the same problems I had...
I recently upgraded SBS to Service Pack 1 and now I am ready to try again and have another look at OWA and eventually RWW.

Daniel