InTheWayBoy

Member
  • Content count

    710
  • Joined

  • Last visited

Community Reputation

0 Neutral

About InTheWayBoy

  • Birthday 09/02/1980

Contact Methods

  • Website URL
    http://www.inthewayboy.com
  1. 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!
  2. 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.
  3. And here is a different sites take on the same issue: http://www.petri.co.il/problems_with_forms..._activesync.htm
  4. 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
  5. 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?
  6. 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.
  7. 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
  8. 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.
  9. 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?
  10. 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.
  11. Could also use ldap editing tools...ldapeditor is a decent one, lets you import/export easily.
  12. 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.
  13. 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.
  14. 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.
  15. Actually, I see you say you're using SP2, which requires a slight tweak: http://blog.stealthpuppy.com/windows/windo...-service-pack-2