Re: Importing .adm settings to other domain controllers

Oh yes, that is an entirely different context than what I was first
envisioning from initial post (at least until your last sentence
where you acknowledge cases where package is not delivered
lock stock and barrel, DC, wire, etc. included).

One thing I will mention first off is to consider use of a post-install
report via the RSoP apis, for the DCs and clients, and then parsing
out from the report the settings that are critical for compliance.
Give this to them as a maintainance utility, or schedule with alerting
to log, email, etc.. but it would seemingly make for a good way to
guard your liability exposure relative to regulatory actions.

For firewall, you may want to consider firing off "netsh firewall"
context commandset, and/or for Vista with advfirewall context,
so that the local firewall policies are set in event that for some
reason GPOs get mucked, unlinked, or client system otherwise
falls out of GPO scope.

I believe you definitely need to approach product delivery
using two distinct scenarios: turnkey system, DC(s) included;
and, up-rev of pre-existing to "dedicated" usage for your product
(i.e. steering away from being "just an application suite" to install
into an existing domain deployment).

Clearly the first of these you can control pre-ship.
The last might be accommodated with such as backup/restore
capability introduced by GPMC, with doc/instructions that the
restored GPO should be compared for incompatibilities with
existing, but that all of its settings need to be the effective one,
whether the admin links it at top priority as is or first adjusts
for "omissions" in some policies that will apply without merge
of earlier (probably mostly an issue in user rights area).
Then you would be delivering restorable GPOs and their
custom adms, sceregvl.inf if you are adjusting there, etc.
plus some guidance (that ends with, run supplied compliance
checker).

"verviflox" <dontsendhere@xxxxxxxxxx> wrote in message
news:OBQyVsNPHHA.1280@xxxxxxxxxxxxxxxxxxxxxxx
Thanks Roger and Mark, you can see part of our dilemma. If I explain the
application a little maybe the question will make more sense. The
application relies heavily on network collaboration XML based workflow
with anywhere from 5 to 100 client workstations in the hospital. The
entire system is delivered as one package (domain controller,
workstations, OS, network cable, ...). The hospital technical staff will
set everything up, and coordinate installation of third party modules that
are designed specifically for our application. These third party
applications in some cases even create their own instance of MSDE SQL
Server. A variety of software will exist on the clients.

The workstations will share some very sensitive information. We must
ensure that the domain controller policies lock down the system as much as
possible while allowing the application to run, and without causing
problems for the third party modules. Our application also sets specific
rights on the filesystem for the various privilege levels. We can't trust
that the technical staff will be experienced enough in all cases to create
their own home-grown domain policies, but we can trust them to follow some
instructions in the install manual. Our application requires specific
application exceptions for the Windows Firewall domain profile, for
example, for which there is a setting in the default Microsoft .adm
template. We also have to lock down some other standard machine security
settings that exist in the Microsoft provided .adm, and a few reg keys
where we have to disable workstation features even beyond what exists in
the standard templates.

We are putting the final installer package together, and trying to figure
out a way to get these specific settings into the domain controller while
minimizing human error during configuration. It would be fine if we could
provide some .inf files that the domain administrator would have to
import, as long as the settings could be applied in a way that the
administrator could merge without wiping our their entire domain policy
setup (in some environments customers want to re-use existing domain
controllers and workstations, bring them up to our higher security
compliance regulatory requirements, and make it all work).




"Roger Abell [MVP]" <mvpNoSpam@xxxxxxx> wrote in message
news:u29RB9IPHHA.404@xxxxxxxxxxxxxxxxxxxxxxx
If you were to provide firewall exemption policy how would you
do that in a manner that respects what is already being set ??

Personally, if I have software that adjusts my config I want it to
let me know that I need to do that, perhaps ask if I would like it
to do it for me, etc. but I do not want software that just does it,
and certainly not if it does what is good for it but is not aware
of how that may not be good for me / my deployment.

Hence, in making software purchase choices, I expect to see
all such needs called out in the installation requirements docs,
and contrary to an all to common practice in the industry, I do
want access to the fully detailed requirements doc prior to
purchase (else no purchase).

Those comment are about software for a client system.
Here, where you are talking about making domain level
adjustments, multiply those comments by 1000 (or more).
How would you know which GPOs to impact?

Your best route is to inform, but leave these highly situational
adjustments up to those that manage their domain.

Roger
"verviflox" <dontsendhere@xxxxxxxxxx> wrote in message
news:un0VlGFPHHA.3552@xxxxxxxxxxxxxxxxxxxxxxx
We will provide some .adm settings for our application because it is
used in a domain environment. These settings can
override/supplement/replace whatever .adm settings the customer
currently has on the domain controller. What would be the best way to
package this as we release the product? We would like to make it easy
for the customer to install (for example, firewall exceptions are
configured in this .adm, amonst several other settings).








.

Relevant Pages

  • Re: Importing .adm settings to other domain controllers
    ... anywhere from 5 to 100 client workstations in the hospital. ... and coordinate installation of third party modules that are designed ... that the domain controller policies lock down the system as much as possible ... out a way to get these specific settings into the domain controller while ...
    (microsoft.public.windows.group_policy)
  • Re: Network + AD = Tighten Security
    ... > addition I would enable auditing of logon events on the domain controller ... > zones of your users to have minimum settings and taking advantage of the ... If you do not want users to install unauthorized software ... You should also run Microsoft Baseline Security ...
    (microsoft.public.win2000.security)
  • Re: cache desktop
    ... >If the Domain Controller is not available (like when we ... >their settings at the same time. ... >icons that are showing up)...so all these foreign icons ... >workstations and they don't go away once the DC is back ...
    (microsoft.public.win2000.group_policy)
  • cache desktop
    ... You know how our public workstations get their ... If the Domain Controller is not available (like when we ... their settings at the same time. ... icons that are showing up)...so all these foreign icons ...
    (microsoft.public.win2000.group_policy)
  • Re: setting up workstations with outlook 2000 allready installed
    ... I just did a similar install, the "usual process" is used, and you do have ... > workstations to the new domain, or is there another process to join these ... > the Outlook 2003 and their existing settings. ...
    (microsoft.public.windows.server.sbs)