+ Post New Thread
Page 3 of 4 FirstFirst 1234 LastLast
Results 31 to 45 of 52
Windows Server 2008 R2 Thread, Brand new Active Directory - From scratch in Technical; Originally Posted by karlr Another big concern is user profiles; We currently use roaming profiles for staff and this leads ...
  1. #31

    seawolf's Avatar
    Join Date
    Jan 2010
    Posts
    969
    Thank Post
    12
    Thanked 287 Times in 219 Posts
    Blog Entries
    1
    Rep Power
    176
    Quote Originally Posted by karlr View Post
    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.

  2. #32

    tmcd35's Avatar
    Join Date
    Jul 2005
    Location
    Norfolk
    Posts
    6,053
    Thank Post
    896
    Thanked 1,008 Times in 821 Posts
    Blog Entries
    9
    Rep Power
    349
    Quote Originally Posted by karlr View Post
    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.

  3. #33

    tmcd35's Avatar
    Join Date
    Jul 2005
    Location
    Norfolk
    Posts
    6,053
    Thank Post
    896
    Thanked 1,008 Times in 821 Posts
    Blog Entries
    9
    Rep Power
    349
    Quote Originally Posted by burgemaster View Post
    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 (C) computer, (U) user or (L) for loopback. Then the general area and then description of the GP, e.g....

    "(C) - 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.

  4. #34

    localzuk's Avatar
    Join Date
    Dec 2006
    Location
    Minehead
    Posts
    18,496
    Thank Post
    526
    Thanked 2,638 Times in 2,042 Posts
    Blog Entries
    24
    Rep Power
    895
    Quote Originally Posted by karlr View Post
    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).

  5. #35

    Join Date
    Mar 2013
    Location
    Shipley. West Yorkshire
    Posts
    21
    Thank Post
    4
    Thanked 3 Times in 3 Posts
    Rep Power
    4
    Quote Originally Posted by localzuk View Post
    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!

  6. #36

    Join Date
    Nov 2006
    Location
    Redcar
    Posts
    62
    Thank Post
    0
    Thanked 3 Times in 3 Posts
    Rep Power
    17
    Quote Originally Posted by seawolf View Post
    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
    Last edited by cogrady84; 28th February 2014 at 02:54 PM.

  7. #37

    seawolf's Avatar
    Join Date
    Jan 2010
    Posts
    969
    Thank Post
    12
    Thanked 287 Times in 219 Posts
    Blog Entries
    1
    Rep Power
    176
    Quote Originally Posted by cogrady84 View Post
    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)

  8. #38

    Join Date
    Nov 2006
    Location
    Redcar
    Posts
    62
    Thank Post
    0
    Thanked 3 Times in 3 Posts
    Rep Power
    17
    "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.

  9. #39

    seawolf's Avatar
    Join Date
    Jan 2010
    Posts
    969
    Thank Post
    12
    Thanked 287 Times in 219 Posts
    Blog Entries
    1
    Rep Power
    176
    Quote Originally Posted by cogrady84 View Post
    "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.

  10. #40

    Join Date
    Nov 2006
    Location
    Redcar
    Posts
    62
    Thank Post
    0
    Thanked 3 Times in 3 Posts
    Rep Power
    17
    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.
    Last edited by cogrady84; 1st March 2014 at 01:50 AM.

  11. #41

    seawolf's Avatar
    Join Date
    Jan 2010
    Posts
    969
    Thank Post
    12
    Thanked 287 Times in 219 Posts
    Blog Entries
    1
    Rep Power
    176
    Quote Originally Posted by cogrady84 View Post
    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".

    Quote Originally Posted by cogrady84 View Post
    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.

  12. #42

    Join Date
    Nov 2006
    Location
    Redcar
    Posts
    62
    Thank Post
    0
    Thanked 3 Times in 3 Posts
    Rep Power
    17
    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

  13. #43

    seawolf's Avatar
    Join Date
    Jan 2010
    Posts
    969
    Thank Post
    12
    Thanked 287 Times in 219 Posts
    Blog Entries
    1
    Rep Power
    176

    Brand new Active Directory - From scratch

    Quote Originally Posted by cogrady84 View Post
    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.
    Last edited by seawolf; 1st March 2014 at 03:18 AM.

  14. #44
    detjo's Avatar
    Join Date
    Feb 2008
    Posts
    398
    Thank Post
    14
    Thanked 61 Times in 51 Posts
    Rep Power
    33
    If .local isnt a good idea, could always use local.

    ie: local.schoolname.sch.uk

  15. #45

    SYNACK's Avatar
    Join Date
    Oct 2007
    Posts
    11,271
    Thank Post
    884
    Thanked 2,749 Times in 2,322 Posts
    Blog Entries
    11
    Rep Power
    785
    Quote Originally Posted by seawolf View Post
    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.



SHARE:
+ Post New Thread
Page 3 of 4 FirstFirst 1234 LastLast

Similar Threads

  1. Replies: 10
    Last Post: 16th January 2012, 11:00 AM
  2. Importing new users into Active Directory
    By Mr_M_Cox in forum How do you do....it?
    Replies: 16
    Last Post: 4th November 2008, 12:36 PM
  3. Replies: 2
    Last Post: 28th November 2007, 05:40 PM
  4. Replies: 3
    Last Post: 16th November 2006, 10:55 PM

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •