Re: Force local policies

Thanks for the help. I'm not saying that all local policies should
always be allowed to override domain policies - particularily not on
PCs. I'm just saying that as an embedded developer, it would be nice
if we could specify some local policies that aren't overridden when the
device is joined to a domain. Then Steves wouldn't have to distribute
a set of policies and hope the admin actually uses them. I'd like to
be able to say "This is how the device behaves" and know that it won't
change regardless of whether it's on a domain or not.

KM wrote:
travisr,

I agree that a device should follow the network rules of a domain but
there are some policies that don't affect how the device interacts with
the network (like 'look and feel' options) where it would be nice if
that could be retained on an embedded device. Regardless, as I've

Well.. I am still no with you here.
E.g., well-known 'look&feel' related policies of Explorer to provide user access to some system folders or, even more, hide/show
some drives. This is often used in domain environments by administrators as a way to protect workstations from a mess that end user
might be able to easy create if he'd have access to the system drives and folders. If local policies came first, domain
administrators wouldn't have a way to protect the network from "curious users".
I believe that for an embedded device if certian functionality is not required it should be removed, not disabled by a policy or
etc.
Or, as Steves pointed out, it is always a good option to create an exception for a set of [embedded] devices and give the network
administrators the policy set you're looking for those devices. Then they, the administrators, would be in control of the things
there as it should be in domain environment.

learned more about the extent to which domain policy can control the
user interface and behavior I've decided we should probably just
completely eliminate domain support for our device. To accomplish
this, I believe you referred to excluding the 'Netlogon/Netjoin'

Yes, that's what I meant. This component is responsible for joining your target computer to a domain.

component - but a dependency trail can be traced from this back to
'FBA: SCE' and then 'Windows Logon (Standard)'. Does anybody know if
it is safe to exclude the 'Netlogon/NetJoin' component despite these
dependencies?

Yup, it is safe to remove this component if you have no plans on joining a domain from the target.
In fact, we've got a bunch of network enabled images without that component included.

--
=========
Regards,
KM



KM wrote:
travisr,

I'm far from being an IT guy, so excuse me if it sounds like I don't
know what I'm talking about. Anyway, as I understand it, a computer on
a domain will always override local policies with domain policies, if
the policy exists on the domain. What I would like to achieve is to
allow users to add the XPe installation to a domain but still guarantee
enforcement of certain local policies. Does anybody know if there is
any way to achieve this?

I don't know any way how to force local policies over domain ones unless it is set up on the server side. Although I am not an IT
guy either and therefore not an expert in this.
It does make sense, however, that domain policies are always on top of the local ones. Otherwise, corporate (domain) users would
be
able to set up thier workstation as they wish and easy break administring and maintating the network.

If not, perhaps this is something somebody
from Microsoft might want to take under consideration - it may not make
sense for a PC but for an embedded product it certainly does.

I disagree. If you connect your embedded product to a network (and, worse, your product runs *PC* software) it must obey to the
network rules set up by administrators of that network. You want to join a domain, you will have to use the domain rules. This is
my
opinion.

Also, if it isn't possible to ensure local policies are retained, can
anybody tell me how to disable the ability to add a system to a domain
without sacrificing other networking capabilities. Thanks in advance.

Well, not quite sure what networking capabilities you are interested in?
After all, you can always remove Join Domain component from your config and that will break the device ability to login to a
domain.
Networking would work as it did before you removed the component. Some domain related stuff, of course, wouldn't work.

--
=========
Regards,
KM


.

Relevant Pages

  • Re: Force local policies
    ... E.g., well-known 'look&feel' related policies of Explorer to provide user access to some system folders or, even more, hide/show ... This is often used in domain environments by administrators as a way to protect workstations from a mess that end user ... If local policies came first, ... administrators wouldn't have a way to protect the network from "curious users". ...
    (microsoft.public.windowsxp.embedded)
  • Re: Force local policies
    ... enforcement of certain local policies. ... If you connect your embedded product to a network it must obey to the ... you can always remove Join Domain component from your config and that will break the device ability to login to a domain. ...
    (microsoft.public.windowsxp.embedded)
  • Re: Dropping Netbios over TCP?
    ... Administrative Tools/Local Security Policy. ... Local Policies and click on User Rights Assignment. ... In the right pane double click on Access this computer from the network. ... > So if I want to keep using 'net use', I have to keep NetBIOS over TCP/IP ...
    (microsoft.public.win2000.networking)
  • Re: Re-occuring error message SceClient 1202 Application Log error
    ... "local policies" vs "Local settings" and there were 3 ... other places other than "access this computer from network", ... > rights assignments. ... > expands them and remove the account. ...
    (microsoft.public.windows.server.migration)
  • Re: Trouble mapping drive
    ... Some settings I would check in gpedit.msc are the following: ... computer from the network ...
    (microsoft.public.windowsxp.general)
Loading