Archived from groups: microsoft.public.win2000.group_policy (
More info?)
Axel,
I assume that you mean that this is a single domain that covers 20 Sites?
If this is the case then there are several possibilities.
First and foremost you need to make sure that a client in Site17 is going to
authenticate against a Domain Controller in Site17 and that a client in
Site04 is going to authenticate against a Domain Controller in Site04.
Please take a look at the following MSKB Article:
http://support.microsoft.com/?id=306602
You do not tell us if you are using the Hub and Spoke or some other method.
Also, do you have a Domain Controller in each Site ( preferably two )? How
many users are in each Site? What are the connection speeds between the
Sites? Also, did you disable the KCC and create everything yourself or is
the KCC doing everything ( with it's friend the ISTG )? How is you Domain
organized - meaning, what does the Active Directory Users and Computers MMC
look like ( do you have an OU for each Site or for each Country or what )?
I saw something in another post that is interesting. I would normally make
a vanilla suggestion that you create a Site GPO for the software deployment.
Granted, this is a possibility. Maybe not the best way, though.
You can put the .msi file in a directory structure on a local Server (
either a Domain Controller that is acting as a File Server or a Member
Server that is acting as a File Server ), create the GPO at the appropriate
level ( either Domain or OU ), point to the .msi file on that Site's local
Server and use Security Group Filtering ( whereby you remove the
Authenticated Users from the Security Tab and create a Security Group and
populate it with the user account objects of the users in that particular
Site - make sure to give that group both the READ and APPLY GROUP POLICY
rights ). Here is an example:
Let's look at the Zuerich, Bern and Basel Sites. Let's say that you have
two Domain Controllers in each Site: ZURDC01 and ZURDC02 in Zuerich, BRNDC01
and BRNDC02 in Bern and BSLDC01 and BSLDC02 in Basel. Say that there are 80
users in each Site and we are deploying Office XP via GPO to all of your
users ( advanced Assigned to the user configuration side so that you can
make use of .mst file ). Furthermore, let's say that you have created an OU
for each location ( Site ).
So, for the Zuerich Site you would do an Administrative Installation of
Office XP on ZURDC02 in the shared ZUROFFXP shared folder. When you create
the GPO for your Zuerich users you *could* link it to the Zuerich OU and
when you tell AD where to look you would use \\ZURDC02\ZUROFFXP\data1.msi as
the path ( notice that this is a local server for that Site ) and you would
remove the AUTHENTICATED USERS group from the GPO security and create a
Security Group ( ZuerichUsers or whatever you want to call it ) and make
each user account object from the Zuerich Site a member of that security
group. You would replace the AUTHENTICATED USERS group with this group (
ZuerichUsers ) and make sure to give that group both the READ and APPLY
GROUP POLICY rights.
For your Bern Site you would do an Administrative Installation of Office XP
on BRNDC02 in the shared BRNOFFXP shared folder. When you create the GPO
for your Bern users you *could* link it to the Bern OU and when you tell AD
where to look you would use \\BRNDC02\BRNOFFXP\data1.msi as the path (
again, notice that it is a local server for that Site ) and you would remove
the AUTHENTICATED USERS group from the GPO security and create a security
group ( BernUsers ) and make each user account object from the Bern Site a
member of that security group. You would replace the AUTHENTICATED USERS
group with BernUsers and give that group the READ and APPLY GROUP POLICY
rights.
For your Basel Site you would do an Administrative Installation of Office XP
on BSLDC02 in the shared folder BSLOFFXP. I think that you see from the
above two examples of what you *could* do....
The key points to this method are that the Administrative Installation is on
a local ( read: local to each respective Site ) and that we are using a
Security Group to filter the GPO. You could link these GPOs either to the
domain or to an OU....depending on how you have things set up. You also
have the option of doing this to the user configuration side or to the
computer configuration side.
However, this is something to consider.
I would first focus on getting everything in AD correct with respect to
logon requests being authenticated by the correct Domain Controller(s).
HTH,
Cary
"Axel Boggio" <axel.boggio@str_yker.com> wrote in message
news:mn.5b1a7d486f5dc068.12023@stryker.com...
> Hi Ken,
>
> This is single domain
> Ken submitted this idea :
> > Just an idea--do you have multiple sites/domains in AD or
> > is it just one large domain with 20 physical disparate
> > locations?
> >
> > Ken
> >
> >> -----Original Message-----
> >> Hi all,
> >>
> >> We have a unique European domain with 20 sites link through the WAN.
We
> >> use GPO's to deploy application. My problem is that when a user based
> >> in Switzerland connects to a site elsewhere and there is a software
> >> update (like MS Office) the installation starts and takes ages.
> >>
> >> Is there a way to block GPO deployment by IP address or better, to
just
> >> allow GPO deployment based on client IP address. Please note that as
we
> >> have a Windows 2000 domain, we cannot use WMI filtering.
> >>
> >> Thanks in advance
> >>
> >> Axel
> >>
> >> --
> >> This is an automatic signature of MesNews.
> >> Site :
http://mesnews.no-ip.com
>
> --
> This is an automatic signature of MesNews.
> Site :
http://mesnews.no-ip.com
>
Facebook
Twitter
Instagram