Gordon Rowell <[EMAIL PROTECTED]> said:
> And I have seen this with MS SBS and an e-smith server. Both were in the > same workgroup, but had different server names. Both were providing > the logon service, but the logon scripts were on the SBS machine. The > e-smith server always answered first. Then you need to fix the client, not disable the feature at the e-smith server :) At the client you need to manually specify the logonserver. Different for every Windows version. For WinNT/W2K to specify a domain server that validates a user logon, set the environment variable %LOGONSERVER% to \\servername then use %LOGONSERVER% in the logon script path statement. > Darrell, > > What we're suggesting is to apply the existing guarding of the > [netlogon] share to the new [Profiles] share. > > I believe the printer$ share does not need to be so guarded as you will > know which server has the printer, but my belief is that profile support > is advertised on the network in the same way as logon support. And using the %LOGONSERVER% sets this for the profile as well. There are many Windows environments in use with multiple domains, PDC, BDC and workgroup servers all sharing the same LAN/WAN. Yes each domain has one PDC but there can be multiple domains and workgroup servers all interconnected. Large campuses, corporate clients. > To recap - the shares will all be there in the normal case. What would > be the reason to have them available if SambaDomainMaster=no? Because you can still run the netlogon.bat file, even if the server is in workgroup mode, as long as the netlogon share is active in workgroup mode. The situation arises in many DOS/Win3x computer and non-peopled computer environments. Security monitoring stations, fire controllers, PLC controllers, any old single app DOS/Win3x computer. DOS/Win3x can not validate to a PDC nor do you want or need these computers connecting into your main PDC domain. You can't have two PDC in your domain so you can't set the e-smith server as a PDC, but you may still want access to the netlogon share and netlogon.bat. You can implement (manually) an effective netlogon.bat to automate the connection process and drive mappings into the workgroup server, but of course the workgroup server must have the netlogon share active. All I'm pointing out is that an active netlogon, printer, or profile share has been thoroughly tested and up until this recent decision to change it, I thought it worked just fine. If the only negative is the one you mentioned above, then I've provided the answer. Fix the client, don't disable the feature at the e-smith server :) Regards, -- Darrell May DMC Netsourced.com http://netsourced.com http://myEZserver.com -- Please report bugs to [EMAIL PROTECTED] Please mail [EMAIL PROTECTED] (only) to discuss security issues Support for registered customers and partners to [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org
