[wpkg-users] [Bug 32] Server(s)/drive letter enhancement

[bugzilla-daemon at wpkg.org]

Please reply using this URL only: http://bugs.wpkg.org/show_bug.cgi?id=32





------- Additional Comments From djf at assetsw.com  2006-09-03 07:10 -------
(In reply to comment #5)
> (In reply to comment #4)
> 
> > - Workstation boots
> > - Workstation asks for DHCP info
> > - Workstation gets DHCP info
> > - Workstation asks Microsoft DNS for its logon server (proprietary)
> > - MS DNS reponds with the logon server assigned to the site the workstation's
> subnet belongs to (from AD sites and services)
> > - Workstation then uses that as the logon server
> 
> I could make %LOGONSERVER% variable recognized only after a real user has logged
> on on a given machine (i.e., in a logon script).
> 
> > This is just for clarity.  Windows workstations that are joined to a domain 
> > always know where their logon server is regardless of whether a user is logged
> > in or not. 
> 
> If I remember correctly, %LOGONSERVER% is not recognized if one runs a command
> via a Task Scheduler, even when executed as a domain user (for example,
> DOMAIN\Administrator).
> Or, this was because I used Samba, which would be an equivalent to NT4 domain,
> which doesn't use DNS.
> 

Correct.  The LOGONSERVER environment variable is assigned via the logon process only after a user logs into the workstation.  However, the workstation itself must know which DC it's using prior to any user attempting to log in to a domain.  For AD, the DC for the site a particular workstation is a member of provides all of the group and domain policies for that workstation.

You can use WMI to get the current domain controller the workstation is using for authentication and system services.  Lookup the Win32_NTDomain class on MSDN.  There are some scripting examples that show how to pull stuff from WMI if you're not familiar with doing so.

Remember, when you run a command via the task scheduler, if you don't provide a specific username, that task will run as the local SYSTEM account.  The SYSTEM account is localized to the box, and therefore won't provide the standard login services you'd get if you login interactively as a domain authenticated user.  Like I said above, if you are running a command as a user that's local to the box, you'll need to script against WMI in order to determine which domain controller the workstation is currently using.

Given that, however, this whole discussion is of little use for this particular feature enhancement.  The feature enhancement he's provided simply lets him have a standardized package.xml file that allows him to always run from the local O: drive, which is pretty important in order for WPKG to scale to larger than a couple sites, and specifically if the WAN links available are low bandwidth.  Seems like a pretty good change to me.

Oh, and on your Samba comment, none of this needs to be absolutely determined via the boot sequence I posted.  For Windows clients using a Samba domain, they simply use WINS to determine what the DC for the current workstation should be.

Incidentally, I'm the David Fenwick at <A HREF="http://us4.samba.org/samba/team/">Samba Team</A>

-- 
Configure bugmail: http://bugs.wpkg.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.






_______________________________________________
wpkg-users mailing list
wpkg-users at lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users