Brand new Active Directory - From scratch

[Out_of_Sync]

Hi,

 

why do you feel .local for a domain is not acceptable? I see mention of .internal and I don't understand what the difference would be. Anyone care to explain?

 

thanks

[localzuk]

Hi,

 

why do you feel .local for a domain is not acceptable? I see mention of .internal and I don't understand what the difference would be. Anyone care to explain?

 

thanks

 

The post above explains why .local is a bad idea. It is a reserved name used by mDNS.

[karlr]

@Out_of_Sync see .local - Wikipedia, the free encyclopedia

 

@burgemaster Our current GPOs are set up similar to this. Each individual software package has its own GPO object, and even individual settings like "always wait for network" seem to have their own dedicated GPO. I can certainly see some of the appeal to doing this, but I believe it goes against Microsoft best practise. IIRC you should avoid having more than 9 GPOs active on a single scope. In a previous school I created GPOs containing all of our general settings, and then assigned to them to the root of the Computers/Users OU. Then each layer down would contain a GPO containing the more specialized settings (e.g. "Student Computer Policy"), and so on.

 

Software installation can be done from a single or maybe a few high level GPOs, and then computers added into security groups to enable that software for them (another big thing we want to do is have all file server permissions controlled by groups, e.g. "Student Share RW" or "Student Share RO" rather than granting permissions to groups like "Students" or even directly to users).

 

@psydii hm, that doc does seem to suggest that two DCs are the recommendation for a single domain/site.

[Out_of_Sync]

thanks for the info.

[karlr]

Another big concern is user profiles; We currently use roaming profiles for staff and this leads to an awful lot of problems. No doubt Win 7+ will handle this better, with increased support for redirection etc, but it's still a worry. I'm also not able to find any proper, clear guidance from Microsoft on this.

 

Edit: Actually I did bookmark and plan to read through http://www.grouppolicy.biz/2010/08/best-practice-roaming-profiles-and-folder-redirection-a-k-a-user-virtualization/ - but what are you guys doing in terms of profiles?

Edited February 6, 2014 by karlr

[seawolf]

Another big concern is user profiles; We currently use roaming profiles for staff and this leads to an awful lot of problems. No doubt Win 7+ will handle this better, with increased support for redirection etc, but it's still a worry. I'm also not able to find any proper, clear guidance from Microsoft on this.

 

Edit: Actually I did bookmark and plan to read through How to configure Roaming Profiles and Folder Redirection - but what are you guys doing in terms of profiles?

 

We don't use roaming profiles here. That was tried in the past, but there were frequent problems. We make heavy use of folder redirection, which works fantastic with no corrupt profiles or super long login times during network load. It does mean the initial login on a PC takes around a 1 minute on average to create the account and up to 2 if the network is really busy. Subsequent logins are very quick though and 1-2 minutes is perfectly acceptable to me because I know it is the upper limits a user will have to wait.

 

Perhaps others have had more success with roaming profiles, but I just kind of gave up on them a few years ago.

[tmcd35]

Another big concern is user profiles; We currently use roaming profiles for staff and this leads to an awful lot of problems. No doubt Win 7+ will handle this better, with increased support for redirection etc, but it's still a worry. I'm also not able to find any proper, clear guidance from Microsoft on this.

 

Edit: Actually I did bookmark and plan to read through How to configure Roaming Profiles and Folder Redirection - but what are you guys doing in terms of profiles?

 

I had a recent thread in BTRD on just this. I've tried just about every method under the sun and they all have their problems. Suppossidly Madatory Profiles are the real solution but I could never get them to work (most likely a permissions problem somewhere). As per what @seawolf said - folder redirection is the key, atleast under Windows 7. The problems I get now appear more hardware/network related than profile related.

[tmcd35]

With our rebuild we did the following which we found helped us....

 

1) We tried to create individual policies for different settings. Only the Student and Staff Default policies have multiple settings ..

 

2) Label each GP clearly. All computer policies begin with © computer, (U) user or (L) for loopback. Then the general area and then description of the GP, e.g....

 

"© - SW INSTALL - Install Flash player"

 

If they call a script add (Script) on the end.

 

3) Not sure if this helps with performance but disable the USER section on all COMPUTER policies and vice versa.

 

Goodluck

 

I'm a believer in fine grained GPO's, provides more flexibility. The only thing to warey of here is not going too fine grained. eg. Individual policys for different settings. The greater the number of GPO's you create the longer it's going to take to evaluate those policies.

 

I tend to group GPO's into area of responsibility, eg..

 

Computers Staff Stoftware

Users Students Desktop

Users Internet

Computers ICT1 Printers

etc

 

Then apply all settings relating to that responsibility/level in the one policy. So "User Students Desktop" includes folder redirection, user profile, and other general desktop security (locking access to CMD), settings that apply only to students.

[localzuk]

Another big concern is user profiles; We currently use roaming profiles for staff and this leads to an awful lot of problems. No doubt Win 7+ will handle this better, with increased support for redirection etc, but it's still a worry. I'm also not able to find any proper, clear guidance from Microsoft on this.

 

Edit: Actually I did bookmark and plan to read through How to configure Roaming Profiles and Folder Redirection - but what are you guys doing in terms of profiles?

 

I stopped using Roaming profiles here. I switched everyone over to local profiles. We don't even do any redirected stuff (we hit a snag - if we turn on any redirection with local synchronising, login takes 5 minutes due to a black screen. I've tried 5+ hotfixes which supposedly solve this issue and they don't work).

[Si2100]

I stopped using Roaming profiles here. I switched everyone over to local profiles. We don't even do any redirected stuff (we hit a snag - if we turn on any redirection with local synchronising, login takes 5 minutes due to a black screen. I've tried 5+ hotfixes which supposedly solve this issue and they don't work).

 

That's Strange, I've got Folder Redirection and takes about 10/20 seconds to login. After i rebuilt most of the the group policy, left by my predecessor. Hoping to move to a fully visualized system, when i get some new servers as well!

[cogrady84]

I'm not surprised your sole user has had issues. Here are some things you are likely to come across at one time or another:

 

1. Inability to bind to AD domain or losing the AD domain bind. This seems occur periodically with various releases on both the Mac and Windows server side

2. VERY, VERY, VERY slow network account logins, sometimes exceeding 5 minutes on the LAN, and taking over 20 minutes for logging onto mobile (network) accounts off the LAN due to the number of timeouts that occur.

3. VERY slow mounting of network drives, slow copying to said drives.

4. VERY slow printing to network printers

5. Major bonjour issues, including for AirPrint and AirPlay on iOS devices.

 

Some links with discussions about these sort of issues commonly faced in .local domains. As I said, .local domains were a cruel joke played on the world by being in Microsoft's "Best Practice" documentation that was then espoused by MS technicians the world over.

 

1. Since Mountain Lion, I no longer have any binding/rebinding issues in my .local domain

2. This is probably due to mounting AD home folders and indexing them on the fly, especially mobile accounts, not having a .local domain suffix

3. Same as 2.

4. Again, no issues with this whatsoever

5. Can't really comment on this as we don't use these technologies at present

 

I think alot of these issues may not be exclusively linked to the .local domain suffix, but a number of factors with the entire installation, although I am only running ~60 AD bound macs. I realise .local suffix can have an impact on Bonjour and mDNS, but alot of these problems were fixed with OSX updates and various workarounds server-side. Given the opportunity I would probably move away from .local to alleviate any future problems, but your list of problems can be fixed. Just my 2p

Edited February 28, 2014 by cogrady84

[seawolf]

1. Since Mountain Lion, I no longer have any binding/rebinding issues in my .local domain

2. This is probably due to mounting AD home folders and indexing them on the fly, especially mobile accounts, not having a .local domain suffix

3. Same as 2.

4. Again, no issues with this whatsoever

5. Can't really comment on this as we don't use these technologies at present

 

I think alot of these issues may not be exclusively linked to the .local domain suffix, but a number of factors with the entire installation, although I am only running ~60 AD bound macs. I realise .local suffix can have an impact on Bonjour and mDNS, but alot of these problems were fixed with OSX updates and various workarounds server-side. Given the opportunity I would probably move away from .local to alleviate any future problems, but your list of problems can be fixed. Just my 2p

 

No, these problems do occur due to issues with DNS and a .local domain. Slow mounts are NOT due to mounting AD folders and indexing on the fly.

 

It's fantastic that you seem to have no issues with these things; although, I suspect you maybe just don't realise that you do have problems because a .local domain may all you've ever known in regards to Macs. If so, then what I would liken it to is a man who was the fastest runner in his hometown and thought perhaps he was as fast as anyone, until he saw Usain Bolt run the 100m and then he realised that he was actually much, much, much slower than a real sprinter.

 

With your .local domain, you are probably running a 14 second 100m and thinking it's pretty good when you could be running a 10 flat.

 

I'll quote AntonioRocco in his recent explanation of .local domains and how and why they cause problems:

 

A brief word about .local domains and multicast DNS.

 

All macs regardless of whether it's server or client 'know themselves' by their Bonjour name. As an example this could be MacMini.local or MacMiniServer.local. Bonjour names can be pinged but won't ever resolve as their won't necessarily be a DNS server that will resolve those names to IP addresses. They can also know themselves with fully qualified domain names or hostnames. A hostname is not the same as .local hostname. Hostnames are A records with (ideally) an associated rDNS record. As an example this could MacMini.myschool.net or MacMiniServer.myschool.net. Can you understand the difference? Finally there is also the Computer name itself which - using the same example as before - could be MacMini or MacMiniServer.

 

On Macs themselves it's practically impossible to remove their Bonjour names. Remember Bonjour uses .local and .local in Bonjour terms is not really a 'Mac Domain'. The reason why the advice is given not to use .local as the basis for a Windows domain when contemplating AppleMac integration is because one of the foundations for successful integration is the quality of the Windows DNS Service. If the DNS Service is based around .local there can be confusion with Bonjour - which the Macs are using regardless of anything else - that can result in poor or non-existent login performance as well as other weird and wonderful behaviour.

 

AntonioRocco (ACN)

[cogrady84]

"Poor or non-existent login performance as well as other weird and wonderful behaviour" is not how I would describe the current situation my mac suites find themselves in. We have absolutely no login trouble and performance is on par with our windows network, DNS works flawlessly. I appreciate there "can" be confusion with Bonjour and .local, but I don't experience any...

 

It took a while getting there, and to be honest I can't recall half of the changes made to my DC's and local changes on the mac image before deployment, but everything works quite happily right now.

[seawolf]

"Poor or non-existent login performance as well as other weird and wonderful behaviour" is not how I would describe the current situation my mac suites find themselves in. We have absolutely no login trouble and performance is on par with our windows network, DNS works flawlessly. I appreciate there "can" be confusion with Bonjour and .local, but I don't experience any...

 

It took a while getting there, and to be honest I can't recall half of the changes made to my DC's and local changes on the mac image before deployment, but everything works quite happily right now.

 

Your Macs should login faster than your Windows PCs if everything is working properly. Ours login in half the time the PCs do on a Windows network (it is not a .local domain however).

 

And, you have confirmed that you have had to "hack" your DCs and Mac images to make it work. How does that show that using a .local domain with Macs is a good idea?

You wouldn't have needed to do any of that if you had something other than a .local domain. And, what about the next OSX update or Windows server update that breaks your hacks?

 

Yes, you can certainly get Macs to work on a .local domain, but they will never run as well as they could and you will always run into issues down the road. It's like running a race while carrying a 20K pack on your back. You'll get there eventually, but you sure are making it hard on yourself.

[cogrady84]

I don't recall mentioning hacking anything? I think I made some changes to netbios and signed smb, I didn't hack anything? Also, if you care to take another look at my OP, I specifically said that given the opportunity, I would have preferred to move away from .local

 

To be honest, my macs probably do login faster than my windows pc's in most cases, roughly 15-20 seconds I guess.

 

Your "quoting" things I didn't say and putting words into my mouth, as I did not say using a .local domain is a good idea. However, for some people it may not be an option to just jump in and change their domain name suffix for the sake of a mac suite. Therefore those people may have no option but to attempt an implementation with .local, in which case, my point is that all is not lost.

 

Please stop sensationalizing my posts.

Edited March 1, 2014 by cogrady84

[seawolf]

I don't recall mentioning hacking anything? I think I made some changes to netbios and signed smb, I didn't hack anything?

 

My bad, I took your statement below to mean that it took you a while to work out all of the changes that were required to your DCs and Mac clients to make them work properly in a .local domain. I call changes to standard functionality or workarounds to make something work "hacks".

 

It took a while getting there, and to be honest I can't recall half of the changes made to my DC's and local changes on the mac image before deployment, but everything works quite happily right now.

 

Let me be candid here. I don't know what the point of your original post was for. To prove that it is possible to use a .local domain? Sure it can be done, but let's not encourage anyone to do it because they WILL run into problems and it will never work optimally, in fact it handicaps the Mac right from the start. Let's encourage people to not use .local domains and to know beforehand that they will have problems at some point if they use a .local domain.

 

That is the advice I will always give anyone who asks and it is backed up by fact and experience. Let's not encourage people to go down a road they shouldn't walk.

[cogrady84]

The point of my original post, is to provide a small amount of guidance to those with a pre-existing windows domain, where they have neither the authority or expertise to start fiddling around attempting to change their forest root domain suffix, thereby potentially knacking everything up, for the sake of a small mac suite implementation.

 

These people may need a different solution other than "Don't use .local" and there are solutions out there... simple as that

[seawolf]

The point of my original post, is to provide a small amount of guidance to those with a pre-existing windows domain, where they have neither the authority or expertise to start fiddling around attempting to change their forest root domain suffix, thereby potentially knacking everything up, for the sake of a small mac suite implementation.

 

These people may need a different solution other than "Don't use .local" and there are solutions out there... simple as that

 

Then, please provide the specifics of those solutions. If they are good ones then you will find support here.

 

I for one, would tell someone with a .local domain to fix their domain first before integrating Macs. Most Windows sysadmins don't have the experience to do the workarounds required to make them work tolerably and usually have a bias against Macs in the first place. If you set Macs up to fail with a .local domain at the start, those sysadmins will use every problem as an example of how Macs won't work on a Windows domain.

 

Several schools have told me that Macs can't be integrated successfully into a Windows network, and it's always because of experiences with Macs on a .local, combined with inexperience with Macs.

Edited March 1, 2014 by seawolf

[detjo]

If .local isnt a good idea, could always use local.

 

ie: local.schoolname.sch.uk

[SYNACK]

Your Macs should login faster than your Windows PCs if everything is working properly. Ours login in half the time the PCs do on a Windows network (it is not a .local domain however).

 

Greif, more unfounded, unspecific generalisations.

 

If you have mandatory profiles and well setup gpos on newish pcs they can log in plenty fast. Or if you have older macs they can take some time (hello forced obselesence with 10.released after your mac).

 

If you are not careful you are going to need a new axe after you grind clean through this one.

[seawolf]

Greif, more unfounded, unspecific generalisations.

 

I thought I was quite specific with my generalisations. And they are hardly unfounded as they are based on empirical evidence from my environment, which having a Windows Server 2008R2 backed should favour a Windows client over anything else.

 

If you have mandatory profiles and well setup gpos on newish pcs they can log in plenty fast. Or if you have older macs they can take some time (hello forced obselesence with 10.released after your mac).

We do, the PCs are equivalent in spec to the Macs, and the PCs do login relatively quickly. Just not as quickly as the Macs, both for a user that had never logged on before as well as for a pre-existing user account. However, if we had a .local domain, the PCs would win that battle by a country mile (again based on actual empirical evidence).

 

If you are not careful you are going to need a new axe after you grind clean through this one.

My IT axe was forged in the hell-like fires of 20 years experience in the defence, manufacturing, retail, finance, and education industries. It should last for quite a while.

Edited March 1, 2014 by seawolf

[cogrady84]

I hate macs as much as the next guy, but i'm not the type of sysadmin who just sits there and says no. I tried it, found out the caveats and worked around them. I certainly wasn't about to go start making huge, irreversible changes to my windows domain for the sake of them.

 

Whatever evidence you have that PC's would win the login race "by a country mile" on a .local domain must be flawed, as this is not the case my in my domain, so there must be a solution for others aswell, every network is different.

 

https://groups.google.com/forum/#!topic/macenterprise/HPGr5LWgbBI

http://www.thursby.com/faq/os-x-107-lion-and-local-domains

http://www.thursby.com/local-domain-login-10.6.8

http://support.apple.com/kb/TS4041

Edited March 1, 2014 by cogrady84

[SYNACK]

I thought I was quite specific with my generalisations. And they are hardly unfounded as they are based on empirical evidence from my environment, which having a Windows Server 2008R2 backed should favour a Windows client over anything else.

 

 

We do, the PCs are equivalent in spec to the Macs, and the PCs do login relatively quickly. Just not as quickly as the Macs, both for a user that had never logged on before as well as for a pre-existing user account. However, if we had a .local domain, the PCs would win that battle by a country mile (again based on actual empirical evidence).

 

 

My IT axe was forged in the hell-like fires of 20 years experience in the defence, manufacturing, retail, finance, and education industries. It should last for quite a while.

 

One single environment is not empirical, more like anecdotal but anyhow in your environment and probably many you may be right however without a study across several hundred with it all configured 'properly' as per you the actual definitive specs for defining every case are lost somewhere in unfounded statistics.

 

I'm certain you have many valid points but you are expressing them in a very abrasive way as most of the people on here also have a decade or more of experience to forge their axes. Your experience is appreciated but may be better accepted with a little less edge in the delivery.

Edited March 1, 2014 by SYNACK

[cogrady84]

I'm certain you have many valid points but you are expressing them in a very abrasive way as most of the people on here also have a decade or more of experience to forge their axes also. You experience is appreciated but may be better accepted with a little less edge in the delivery.

 

+1

 

This is kind of what I wanted to say, but couldn't find a way to say it in a non-aggressive way. I have over 12 years experience in this field also, so I am more than comfortable within my own system to fiddle around and make it work, somehow or other.

[seawolf]

I'm certain you have many valid points but you are expressing them in a very abrasive way

 

...and the pot calls the kettle black.

 

I guess you just bring out the abrasive in me SYNACK.