InTheWayBoy

I've never used the built-in VPN abilities of Windows, I've always used OpenVPN. It's open-source and has been developed to run on just about everything. Setup is tricky at first, but after you get used to the config files you'll be running in no time. It's very configurable, and supports your need of the remote endpoint sharing your public ip after connecting...I believe it's called "redirect-gateway". I can't really provide any step-by-steps but there is a wealth of info out there...good luck!

DFS is pretty nice, and it's not that hard to setup. The key to your scenario is setting up your AD sites correctly. The feature that grabs the data from the closest location is based off that. Hopefully you have R2, it's got the latest version of DFS.

And here is a different sites take on the same issue: http://www.petri.co.il/problems_with_forms..._activesync.htm

Oh I'm with ya on that...guess I just worded it incorrectly. My intent was to point out that if you get trained in 2003 a lot of it will still apply to 2008, other than some things being in different places and some new tools to administer. So if he was hesitant to learn 2003 only to 'relearn' 2008 I was just trying to help him understand the two are very similar in that respect. It's Friday and my brain is scrambled so even that might not make as much sense as I think it does

Check the clients DNS settings and Firewall...if DNS is messed up, then it won't find anything, and an improperly configured firewall will block the communication. For starters, in the server address box are you using an IP address or an FQDN? In either case, can you ping that address from a command prompt?

Don't forget to factor in $$$...I haven't seen any numbers on 2008, but I would imagine that 2003 is going to be cheaper. Otherwise go with the latest and the greatest, it'll pay off in the long run since your new skills will be relevant longer. On the flipside, other than some graphical changes administering a 2003 box is about the same as administering a 2008 box...unless it's a core server, then things are a little tricker since there isn't a standard GUI.

So I'm really looking forward to messing with all the new GPO advancements, the virtualization, and I'm really stoked about the SMB2 benchmarks! Now all I have to do is persuade my finance people that we 'need' this...**** the red tape! But for now I'm switching over to 2K8 in all my other projects. First step is to see how many functional Core servers I can virtualize compared to Full servers. I wonder if you could replace all your servers with Core servers and just have one station with all the admin tools on it...I'll let ya know how well that works

I would just scrap any idea of using a windows-based fax program. We use a commercial product, FaxPress, which is a custom server preinstalled with 2003 and the special fax hardware/software. For four lines it set us back about $5000. Works great, but it's $5000. After we got it I found out that a simple linux virtual machine running HylaFax with some rather standard external modems would do the same for about a quarter of that...if even. Of course you'll need some linux skills, but it's almost set it and forget it technology at this point. Also, if you want the ability to fax from the desktop (Like fax a word document) you still can, you just need to convert it to a PDF (PDF Creator comes to mind) and then email it to the HylaFax server with the correct details. It's pretty swank... As a suggestion, no matter what product you get, if you have the choice get external modems. They are infinently more reliable that internal modems, they can be 'hot-swapped' when they die, and you get a nice visual display of the status. I use only USR 5686E's, cost about $80 a pop but they are well worth it.

Looking to phase out the first DC in our network, which is running 2003 SP1 in a virtual server. I want to implement some redundancy by adding another DC/DNS server, but would like them both to be as similar as possible. The new server template I run is 2003 R2 SP2, and the current DC is the last server on the network that isn't at that level. I just want to forget the OS instead of updating it. I've done this before under emergency situations where I could afford downtime, but with this I want to make it smooth. I plan to deploy one new virtual server as a DC/DNS, and let replication handle the heavy work. Then transfer the FSMO roles to the new server, and make it's other services the primary ones (WINS, DHCP, etc) on the network. Once that is stable I'll deploy a second virtual server as a DC/DNS, again letting replication do it's thing. After verifying that I can then remove the first server from AD using dcpromo. Oh yeah, and make sure to make the new virtual servers also GC's. Aside from any major mistakes, I just have a few questions: 1. When it's all said and done should I point the DNS servers to themselves and then the other, or vice versa. I've read both and can't figure out which to go with. 2. We have an Exchange 2003 server, and also use IAS for our vpn authentication. Are there any extra precautions I should take because of their AD requirements? 3. Is there a simple way to verify that replication has completed 100% before I demote the first DC?

As alternatives to the M$ tools (Not knocking them either) you can use KiX or AutoIt, both have some fantastic features. In the end I find you have to use a mixture, some are better than others. KiX has a built-in AD-aware function that parses a users' group membership which makes it ideal for login scripts (Map drives based on group membership). And AutoIt has some amazing GUI manipulation functions that can be your only fix sometimes. And then bat/cmd to stitch it all together.

Could also use ldap editing tools...ldapeditor is a decent one, lets you import/export easily.

You can get around that a few ways...put some kinda registry check in your script before importing the prf. If a profile exists there are certain keys you should be to use in this process. Also, I think there is a way to setup the prf to only create but not modify a profile it it exists, so the first time it would create it but after that it would bypass the prf. I haven't given this enough effort to implement so I might be off on some of that.

Well if you plan on replacing the current domain, even with the same name, I would think you're gonna run into some issues. Nothing you can't fix but it won't be just a simple process. User's profiles and data will have NTFS permission conflicts. If you're running exchange you'll have to deal with that as well since it hosts a major part of itself in active directory. GPO software installations might bug out. If I was doing what you it, I would angle to have all the users create new profiles and use something like xcalcs to edit their personal data to work on the new domain. Get the new domain running in a way that it can't communicate with your current domain, don't want things like DHCP mixing things up for now reason yet. Export as much info as you want from the current domain, at the least usernames and groups so you won't have to manually create them. You can use various tools to get that stuff to ldif files, which is the best for this operation. You should import this first, especially if you export security groups and you want to configure GPO's based off them. Install the same services on the new domain, then configure as necessary. You should let DNS start fresh, nothing from the current domain...same for DHCP and WINS, joining the clients to the new domain should get that all working. I don't know for sure about this one, but I would think you could configure the same GPO software installs. I'm thinking when it logs on to the new domain it will initiate a reinstall of the application. If they are getting new profiles this shouldn't be a big deal unless the software is something special. If you don't do this you might leave orphaned installs on the clients that could be problematic to uninstall/update. Again, I'm not 100% on that. If you run Exchange I would imagine you can export the mailboxes and public folders, along with other config parameters (ldif again). I've never had to do that yet, would kinda give me a reason to re-evaluate the idea. For the clients, I would login as local admin and break it from the current domain to a temporary workgroup. Then remove any profiles, you may want to back them up depending on what they contain. If you do folder redirection you shouldn't have to worry about much. A few tweaks, like ipconfig /flushdns and getting a new DHCP lease from the new domains DHCP server...possibly reseting the local group policy to the factory defaults (That way your new GPO's have a standard config to work with), and then join it to the new domain. You should be able to preprep most of it, and then in one night do the switch over. Of course depends on the number of clients. Almost all of this could be automated if you good at scripting. Your clients will need to be reconfigured, but depending on how in depth your login scripts are it may only be minor things. For my setup each new profile is setup using a combonation of a custom default user profiles and login scripts. But there is always some pains, like printers and such. Oh yeah, you'll have that to worry about too, especially if the printers are hooked up to the clients and shared through AD. Hopefully someone else has some better ideas for ya, mine is a little too manual even for my own taste.

You could always go old-school and script it...I don't have an actual working script handy, but I used to work at a place that limited logins. The domain login script would query the file server to see if the user logging in is already connected to a particular network share. If they are the script halts, warns the user of the double-logon, and logs the user out. Of course this is not a turn-key solution but it's an option that won't require third-party software other than a custom script.

Actually, I see you say you're using SP2, which requires a slight tweak: http://blog.stealthpuppy.com/windows/windo...-service-pack-2

R2 kinda works media center or tablet pc, the first disc is almost exactly like a normal 2003 install with SP1 slipstreamed into it. However there is something that's on the first CD (CDKEY?) that makes it capable of using the second CD, which is the R2 update you're talking about. Without compatible versions you won't be able to just throw R2 on any 2003 machine, it'll give you that error you're talking about.

Thanx for the tips guys...both DC's are GC, and FSMO rules are in the first one for now. We will be adding extra DC's shortly, so I will be playing with the FSMO rules eventually. The Exchange was my biggest fear, mostly just from not knowing. We only have one server currently, seems to be handling the load fine enough for both sites. I'll be jumping on this project over the holiday, so I'll let you know the status of it come Thursday...or earlier if it all melts down

I've got two locations that I admin, each with it's own DC in the same domain. I have setup DFS and want to start using the feature where it will grab data from the closest source so our VPN doesn't get clogged. To do this I see I need to establish another site in Active Directory (Currently everything is in the default site), which seems logical enough. However I've got an Exchange server running, as well as some other resources that I don't know to enough about to determine what the outcome of this will bring. So here are the main questions: 1. Exchange - Will the other site require any different configuration or administration for a user to access the Exchange server via Outlook 2003? 2. Active Directory - I know some thing like GPO's might require me to keep a sharper eye on which site it applies to, but are there any other major changes for standard administration that I should be aware of? 3. DC - Will things like GC and FSMO things change because of having one in each site? 4. Renaming Site - The first site is something annoying like Default-First-Site. I asked one guy about changing the name to something else and he suggested against it for reasons he didn't explain. Is he just blowing smoke or should I not mess with that one? I think those are my current sticking points. We have several users who travel between sites, so getting this fixed will be a big load of my shoulders if I can eliminate the bandwidth issue.

I'm excited about the Server Core aspect, seems perfect for a virtual environment!

Whenever I integrate SATA/SCSI drivers I edit txtsetup.inf and hivesft.inf. I found this process by checking out Dell's XP installs that had the Intel SATA drivers installed and it works with 2K3 too. I copy the driver files to the I386 folder uncompressed. Then I edit hivesft.inf: Replace HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion","DevicePath",0x00020002,"%SystemRoot%\inf" With HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion","DevicePath",0x00020002,"%SystemRoot%\inf;%SystemRoot%\SATA" %SystemRoot%\SATA is the folder that will eventually contain the SATA drivers...looks like it just adds another source for looking for drivers, but honestly I don't know really what good it's for. The I edit txtsetup.inf: [WinntDirectories] 304 = SATA [sourceDisksFiles] PERCSAS.SYS = 1,,,,,,4_,4,1,,,1,4 PERCSAS.SYS = 1,,,,,,,304,0,0 NODEV.INF = 1,,,,,,,304,0,0 OEMSETUP.INF = 1,,,,,,,304,0,0 PERCSAS.CAT = 1,,,,,,,304,0,0 [HardwareIdsDatabase] PCI\VEN_1028&DEV_0015&SUBSYS_1F011028 = "percsas" PCI\VEN_1028&DEV_0015&SUBSYS_1F021028 = "percsas" PCI\VEN_1028&DEV_0015&SUBSYS_1F031028 = "percsas" [sCSI.Load] percsas = PERCSAS.SYS,4 [sCSI] percsas = "PERC 5i RAID" Those are all added, nothing has to be changed in the file. And that's pretty much it, don't need to mess with your unattended file or anything. I got the HardwareIdsDatabase info from the driver's INF files. Here is what the Intel SATA drivers look like: [WinntDirectories] 304 = SATA [sourceDisksFiles] IASTOR.SYS = 1,,,,,,4_,4,1,,,1,4 IASTOR.SYS = 1,,,,,,,304,0,0 IASTOR.INF = 1,,,,,,,304,0,0 IASTOR.CAT = 1,,,,,,,304,0,0 IASTOR.CAT = 1,,,,,,,304,0,0 IASTOR.INF = 1,,,,,,,304,0,0 [HardwareIdsDatabase] PCI\VEN_8086&DEV_2682&CC_0104 = "iaStor" PCI\VEN_8086&DEV_2681&CC_0106 = "iaStor" PCI\VEN_8086&DEV_27C3&CC_0104 = "iaStor" PCI\VEN_8086&DEV_27C6&CC_0104 = "iaStor" PCI\VEN_8086&DEV_27C1&CC_0106 = "iaStor" PCI\VEN_8086&DEV_27C5&CC_0106 = "iaStor" PCI\VEN_8086&DEV_2652&CC_0104 = "iaStor" PCI\VEN_8086&DEV_2652&CC_0106 = "iaStor" PCI\VEN_8086&DEV_2653&CC_0106 = "iaStor" [sCSI.Load] iastor = IASTOR.SYS,4 [sCSI] iastor = "Intel Matrix Storage Manager" I recall seeing issues like what you said before I came to this process, I wonder if it has to do with compressing the driver? BTW, this worked on my 2900.

I finally got around to playing with DFS, the latest version included with 2003 R2...if your servers support that I would highly suggest using that instead. However I don't know how effective it would be with a computer off the domain, don't have that situation to test.

Acronis TrueImage is much better than Ghost, at least to me. Their basic package will b***h about server class OS if you try to run it's windows-based client, but if you boot off their linux-based bootable CD it'll do what you need without a hitch. It's a slick cd actually, nice gui and pretty fast too. Forgot to mention that it support USB, FireWire, DVD, CD, and LAN (FTP or SMB/CIFS) as destination points for the backups, and with the bootable CD you should be able to restore a dead system in no time. The CD pretty much recognizes all SATA, LAN, and pretty much everything else...I had an issue with a new version of the Intel SATA controller but all I had to do was update the app and burn a new CD to boot from.

I wish I could offer more suggestions but the only thing I have to say is look into scripting, lots of common admin tasks can be scripted and run as under the user you want instead of your account or an administrator account. But seriously, knowing anyone's password is not recommended. Something bad happens, things get sticky because it could have been anyone who knew said password. And if you get into things like HIPAA and government policies it's impossible to rely on a system built around knowing a users passwords.

Ehh, ended up going with the trusts...setup a one-way trust from the EMR DC to the correct domain. I cleaned out the EMR's AD, removed all the users and such since that is all handled by the correct domain's DC. So far so good, much easier than I was expecting.

You should just make the jump to RIS, it's not quite the same as what you are trying to do. If properly configured you can: Boot from the network with PXE Install to a blank drive with no previous paritions, and you can create and use NTFS partitions too It handles the shares and image distrobution It authenticates against AD for security If you are concerned about messing with your production servers, then grab a copy of vmware server or ms virtual server or virtualbox (All free virtualization software) and load that up as your RIS server. It's dead simple really, you just install the RIS component (Through Add/Remove Programs, Windows Components) and then you run it's wizard to setup the first image. It will require a CD of the OS you are wanting to install, at which point it will create the correct file structure in the correct place. From there you can follow most unattneded info, it supports answer files and $OEM$ folders and adding extra drivers. But, as you seemed to have found out, network/RIS answer files are slightly different than CD or floppy answer files. Luckily the RIS install provides default answer files that work well with RIS. Also, since it's not loading setup from DOS like you are it's much more efficient and capable. There is a sub-forum on here specifically for RIS installs...lots of good info in there!