RE: [ActiveDir] Why not browsing - was Multihomed Domain Controllers

[Brian Desmond]

The second is to publish resources in Active Directory. This is fairly common for printers though more and more I seem to be seeing people just sticking a sign up on local printers with the queue name and DNS name to avoid someone moron from accidently picking a printer somewhere he shouldn't be printing and sending some huge print job to it. Or even worse, purposely looking for printers with capabilties they want but not really a printer they should be able to use so in order to stop them you have to start ACLing the printers which can be a pain to manage - an example here would be giant plotters capable of doing wall sized plots or really nice die transfer printers or high high end color laser printers.   Ah but one of the benefits of being a domain admin in these large organizations is that you are empowered to test the print queues for these printers to make sure they’re fully functional at all times.   Thanks, Brian Desmond [EMAIL PROTECTED]   c - 312.731.3132   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, July 16, 2006 9:23 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Why not browsing - was Multihomed Domain Controllers   In larger companies browsing really isn't used all that much as there are quite a few things that can screw it up. It is entirely a broadcast based mechanism and I have seen several companies just start disabling the browsing service altogether to help alleviate browe master wars, etc. On 10Mbs ethernet that could be especially problematic and a small scale browse war could saturate the network. If you actually have an issue with browsing you will talk to MSFT and find out that most of that isn't even supported, or at least that was my experience early on when trying to get some support with some browsing issues and started learning how it all works back in about 1997 or so.   So how do people find resources in large companies? A couple of ways:   The first is standard namings of resources. For instance, in one large company there are pretty much only six share names that are allowed   1. SYSVOL for reasons obvious to this crowd   2. NETLOGON for reasons obvious to this crowd plus local member servers used as home drive serves can use this share name if they want to implement secondary logon scripts that are managed by the local site admins   3. The home directory shares on the home server which are named as \\server\samaccountname$ (the $ hides the share from casual enumeration with net view or the Windows standard tools)   4. SDS$ which is a share for the homebrew software delivery system   5. \\server\APPS which is a share that contains all application installation packages as well as apps that run across the network. For the latter say you have a simple app that doesn't need to update the local machine to run, it can be run right from the share. This share was set up as a null session share so even machines could connect and run things from it (say for software delivery) without having to depend on kerberos and specifically granting access.   6. \\server\PROJ which is a share that contains shared project data for the site. There are subfolders under the root of the share that are ACLed for the various groups that need a dedicated folder. The permissions are very simple as well... the groups will be named something like PREFIX-Foldername-R or PREFIX-Foldername, the first gives read access, the second gives change access. The prefix will usually be a site code but if there are multiple proj servers involved it will likely be sitecode-servername.   Usually a given site will have but a single PROJ and APPS server which is usually named sitecode0001. So any site I go into, If I know the site code for the building (which is the start of the name of every PC in the building) then I know how to find proj and apps.   On the occasions (generally rare) that the data for a project needs to be used in another site you are told what the server name is that you need to connect to.     The second is to publish resources in Active Directory. This is fairly common for printers though more and more I seem to be seeing people just sticking a sign up on local printers with the queue name and DNS name to avoid someone moron from accidently picking a printer somewhere he shouldn't be printing and sending some huge print job to it. Or even worse, purposely looking for printers with capabilties they want but not really a printer they should be able to use so in order to stop them you have to start ACLing the printers which can be a pain to manage - an example here would be giant plotters capable of doing wall sized plots or really nice die transfer printers or high high end color laser printers.       -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm        From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rocky Habeeb Sent: Thursday, July 13, 2006 8:25 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Multihomed Domain Controllers Brian,   Could you please explain to me what you mean by "save for the browsing situation, but who uses that anyway?"  Are you saying that your networks don't have browse masters?  How do people find resources then?   Thanks.   RH ___________________________________________ -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Brian Desmond Sent: 13 July, 2006 1:29 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Multihomed Domain Controllers I’ve got hundreds of sites/forests with multihomed DCs. It works fine save for the browsing situation, but who uses that anyway?   Thanks, Brian Desmond [EMAIL PROTECTED]   c - 312.731.3132   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: Wednesday, July 12, 2006 8:36 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Multihomed Domain Controllers   Personally, I've never used that configuration for a DC.  Since being bit in the nt4.0 days (before that really, but hate to show the age :) I've had architectural reasons to not do that.  Since AD is made up of a multi-master fabric, I have had no reason at all to require an isolated network dedicated to backups.  I get the feeling in your case it's just a nice to have vs. a requirement since you have the hardware and figure why not put it to use.  You'd be a rare exception if the size of the dit is large enough to require such a configuration.  Saying that, is it possible? Most likley.  Will it be difficult when/if you call for support for some other issue to explain to the engineer that you have a mutli-homed DC? Most likely.  Does it break the "keep it as simple as possible while meeting the requirements?" rule? Most likley.    When you test this, as the others have mentioned, be sure to test the recoverability and the gotchas that come along with bringing up a recovered DC on a multi-homed machine.  You'll want to have that documented and thouroughly tested so as not to have to deal with that when under pressure.  You may also want to consider an alternative backup method that doesn't require a dedicated network to the DC's.    Just some random thoughts and my $.04 (USD) worth.   Al   On 7/12/06, Jeff Green <[EMAIL PROTECTED]> wrote: Hi Guys,                     Many thanks to all that have responded (and so quickly !)   Points / clarifications / additional Qs       a)    DNS multihomed issues               Yes, found that in the MS KB about not "registering this connection in DNS" on the second NIC.               Also leave the gateway / DNS TCP/IP settings blank on the second NIC.       b)    Browser Issues               Several things in MS KB about this and fixes (including hacking a registry if I remember correctly)                     But would Browser issues affect AD operations - I'm talking about replication issues here ?       c)    Currently running W2K SP4 + rollups on all DCs - but moving to W2K3.              Sorry should have stated this.         d)    Backup              Using BackupExec, which allows binding of remote agents to specific NICs     Have I got everything covered - I can't believe this is an unusual configuration ?                                             Many Thanks                                           From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Jeff Green Sent: 12 July 2006 11:43 To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Multihomed Domain Controllers   Hi,      First posting to this list but I've lurked quite a while and I've been very impressed by the quality of replies by the gurus. My question is regarding the advisability of having multihomed DCs. Basically I want to run backups over a separate GbE and as my servers have dual inbuilt NICs this seems an obvious route to take. I know there are some issues with DNS (I have a DNS integrated AD). Would this cause replication problems, etc ? Any other "gotchas" ?                           Many Thanks, --- Jeff Green Network Support Manager SAPIENS (UK) Ltd t: +44 (0)1895 464228 f: +44 (0)1895 463098 "I dream of hover cars and old transistor radios ... She dreams of flowers in a field of sunny bungalows" ------------------------------------------------------------------------ Confidentiality Note: The information contained in this email and document(s) attached are for the exclusive use of the addressee and may contain confidential, privileged and non-disclosable information. If the recipient of this email is not the addressee, such recipient is strictly prohibited from reading, photocopying, distribution or otherwise using this email or its contents in any way. Please notify the Sapiens (UK) Ltd. Systems Administrator via e-mail immediately at [EMAIL PROTECTED] , if you have received this email in error. Disclaimer: The views, opinions and guidelines contained in this confidential e-mail are those of the originating author and may not be representative of Sapiens (UK) Ltd. ------------------------------------------------------------------------ ------------------------------------------------------------------------ Confidentiality Note: The information contained in this email and document(s) attached are for the exclusive use of the addressee and may contain confidential, privileged and non-disclosable information. If the recipient of this email is not the addressee, such recipient is strictly prohibited from reading, photocopying, distribution or otherwise using this email or its contents in any way. Please notify the Sapiens (UK) Ltd. Systems Administrator via e-mail immediately at [EMAIL PROTECTED] , if you have received this email in error. Disclaimer: The views, opinions and guidelines contained in this confidential e-mail are those of the originating author and may not be representative of Sapiens (UK) Ltd. ------------------------------------------------------------------------