I'm running in to a few complications in my migration process. My main role has been a Linux / Sun administrator for 15 yrs so Windows server 2008 environment is a bit new to me, but understandable.

Here's our situation and reason for migrating...

We have a group of developers that develop VERY low-level software in Visual C with some inline assembler. All the workstations were separate from each other which cased consistency problems with development libraries, versions, etc...

Our goal was to throw them all on to a Windows domain were we can control workstation installations, hot fixes (which can cause enormous problems), software versions, etc... All Development Workstations are running Windows XP x32 (sp3) and x64 (sp2) I running in to user permission problems and I was wondering maybe I missed one, tWO or a handful of things during my deployment.

Here is what I have currently done:

  1. Installed and Activated Windows Server 2008
  2. Added Roles for DNS and Active Directory
  3. Configured DNS with WINS for netbios name usage
  4. Added developers to AD and mapped their shared folders to their profile
  5. Added roles for IIS7 and configured the developers SVN
  6. Installed MySQL Enterprise Edition for development usage

Not having a firm understanding of Group Policy I haven't delved deeply in to that realm yet.

Problems I'm encountering: 1. When I configure any XP workstations to logon our domain, once a user uses their new AD login, everything goes well, except they have very restrictive permissions. (Eg: If a user opens any existing file, they don't have write access, except in their documents folder.) Since these guys are working on low system level events, they need to r/w all files. All I'm looking to restrict in software installations.

  1. Am I correct to assume that I can use WSUS to maintain the domains hot fixes and updates pushed to the workstations?

  2. I need to map a centralized shared development drive upon the users login. This is open to EVERYONE. Right now I have the users folders mapped upon login through their AD profile. But how do I map a share if I've already defined one within their profile in AD?

Any responses would be very grateful.

  1. Do I have to configure and define a group policy for the domain users?

  2. Can I use Volume Mirroring to mirror / sync two drives on two separate servers or should I just script a rsync or MS Synctool? The drives simply store nightly system images.


I don't see anything wrong with what you have done to setup the domain. It seems like you just need a fairly basic setup, and that is what you have running right now.

First your problem with the developers:

The behavior of them having very restricted access is AD working as designed. By default when you join a domain the following happens to your local computer groups:

  • AD Domain & Enterprise admin groups are added to the local admins group
  • AD Domain Users are added to the local users group

So all of your users are (correctly) in the Domain Users group, and only have normal user level access to the workstations.

As far as a solution. That gets a little bit tough, especially when dealing with low level access on a windows system and could depend on when they have issues. Is it when they try to test run the program? Is it when they try to access certain files on the drive while developing?

A few possible solutions I can think of:

  • Make them part of the "Power Users" group on their local machines. That would allow them to have a higher level of access without being full administrators
  • Use Process Explorer to figure out what files/directories they are getting hung up on and give them permissions to just those items
  • Install VMWare workstation, and give them a base image that they can make a copy of then get rid of the copy after they done so they are always working off the same base image (awkward and probably not too feasible but i can't remember if VMWare workstation lets you do snapshotting)

Now on to your questions. I'll take them a little bit out of order, mostly because the answer to 3 or the 4 of them is to learn to use and love group policy. IMHO Group Policy is the killer app in a windows network. I'm not going to delve too deeply in how to set these things up in group policy as that is a little to far reaching for this question - but please search around this site, and ask questions there are a lot of smart people and good information on group policy here.

As far as WSUS goes yes, it will allow you to configure just about every aspect how how WSUS delivers updates to the machines. The actual authorizations for the patches are done via the WSUS interface.

For the drive mappings, my personal preference is to not use the the setting in their AD user object. As you have already found out it is very inflexible. You can do one of two things, both with group policy:

  • Setup a batch file that maps all of the users drives that you want to map and put it in \\<domain>\NETLOGON\<script_name> and assign it as a logon script in group policy.
  • Use the managed preferences (I apologize i forget the exact name off the top of my head) user policies in the GPO to set the mapped drives

With your system images i would go ahead and use rsync if you are comfortable with it DeltaCopy is a windows port that is a little bit more windows friendly. I would stay away from sync toy as i've found it to be pretty slow at large copies. If you want another option you could use robocopy or richcopy and script a scheduled task to copy the files over each night.

| improve this answer | |
  • Thank for your comments as well. With both of you guys experienced help I been able to resolve a couple issues as well as targeting what needs to be done next. Thank you very much, your help is very appreciated and MERRY CHRISTMAS! – DevNULL Dec 17 '09 at 15:25
  • DeltaCopy is a great solution. Being a *nix guy rsync is a preferred option however I'm generally skeptical on application ports from platform to platform. I think I'm going with Deltacopy. Thanks for the suggestion. – DevNULL Dec 17 '09 at 15:32

Ok so... I'm just going to tackle things as I see them. The first thing is add a group for all of your developers, and obviously put them all in it. Then on the local machines add that group to the appropriate local group. What I mean is - if you want them to be administrators add the Developer group you created in AD to the local administrator group (or power users, or wherever you want it). If you want to drill even further down as to what they do/don't have control over you'd have to use group policies for it.

You are correct to assume that you can use WSUS to maintain all the hotfixes and use it to push them down - however you need to set the policy so that the local machines apply the updates, etc.

Can you explain the centralized shared development drive reasoning? Are they all developing out of the same directory? You can accomplish a second share with login scripts - however I'd HIGHLY recommend using source control and let them develop locally, such as subversion.

As far as your volume mirroring you could check into DFS (distributed file system) to synch up those two drives as long as both machines are windows servers.

I'm sure I've missed things but those are just some thoughts at first glance.

| improve this answer | |
  • I do have two SVN servers both on Redhat Ent . The shared resources drive is for testing new libraries, build processes and various and file shares. – DevNULL Dec 17 '09 at 15:29

You're well on the right track.

For doing most of the things you want to do, you will need to learn about Group Policies. They will allow you to do everything.

First, create an Organisation Unit (OU) in your Active Directory to dump all these administrators in. GPOs are most usually applied to an OU, so it means that everyone outside of the OU will not get all their settings.

Secondly, you need to set a GPO for that OU. The GPO will allow you to:

  • Specify WSUS server to use (for forced updates)
  • Map network drives in addition to the one specified in their profile
  • Permit or restrict access rights to the local system
  • Permit or restrict access to install software
  • Even force installation of certain pieces of software (with other appropriately configured services)

If you want to sync two drives on two seperate servers, and they're both running Windows Server, investigate Distributed File System (DFS). It will keep the specified folders on both servers up to date, provides a single point of access, and will failover or load balance depending on how you configure it between the two (or more) servers.

| improve this answer | |
  • THANK YOU VERY, VERY much for you comments and suggestions. I'll be following your instructions exactly as you mentioned. Given that your reply was so concise I'm pretty sure you have the experience (which I lack) as an Windows Administrsator. It's a big jump for me taking over a Windows environment when I've dealt entirely in a RHEL and *nix networks for so long. Thanks again for your help! – DevNULL Dec 17 '09 at 15:12
  • Not a problem. If I had to set up a *nix network I'm sure I would be in a much larger state of confusion than you are! – Mark Henderson Dec 17 '09 at 20:56

For your developers, you may find it reasonable to make them administrators (or power users) of their computer. You can use a GPO to override "Restricted Groups" for "Administrators" or "Power Users" or "XXXX Group".

  1. Create a security group in AD
  2. Add the developers to this security group
  3. Apply a GPO over the computers that the developers use so that under "Restricted Groups" you have "Administrators" with


YOURDOMAIN\Enterprise Administrators

YOURDOMAIN\Domain Administrators

YOURDOMAIN\Developer Security Group

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.