Archived from groups: microsoft.public.win2000.group_policy,microsoft.public.win2000.security (
More info?)
Ummm...errr...uh oh... I posted my results too soon. :-(
So to be clear for any future readers of this thread, my DNS configuration
wasn't actually the problem after all. Nevertheless, I'm still happy with
my new "clean" DNS infrastructure!
It turns out that my particular GPO/EFS-related problem doesn't appear until
a domain user actually ATTEMPTS to encrypt a file on one of my Windows 2000
Server shares. (Note that I wrote 2000 Server...not to be confused with
Server 2003.)
When a Windows XP user attempts to use EFS on their local workstation,
everything works fine, and Windows XP properly honors the Windows Server
2003 setting and disallows the user from encrypting local files. (Note that
this time I wrote Server 2003.) However, when the same user attempts to
utilize EFS on one of our Windows 2000 Server shares, the user's XP Explorer
session locks up, and the Windows 2000 Server practically grinds to a halt.
When I subsequently try to log into the 2000 Server, it takes several
minutes before the login dialog is presented, and the server no longer
thinks that it belongs to a domain. Even when the login dialog is finally
displayed, I can't log into the server because the server doesn't have a
Local Administrator account (remember that it's a domain controller.)
To get out of this predicament, I had to delete my higher-priority "Disable
EFS" GPO on the domain controller that I could still access (Windows Server
2003), and then remotely reboot the Windows 2000 Server by using Computer
Management on the Server 2003 server. Once rebooted--and with the 'Disable
EFS' GPO gone--the 2000 Server is stable again. Yes, the same DNS-related
error is seen in the log (i.e., it was logged once the server went haywire
after the encryption attempt.)
So I've gone back to disabling EFS via the "Default Domain Policy" GPO.
This works and I'm not going to worry about it anymore. My gut tells me
that this is a mixed 2000-2003 domain controller issue, SPECIFICALLY related
to EFS.
Points to remember:
- Infrastructure works 100% until a user actually attempts to encrypt a file
(only on the Windows 2000 Server.)
- The problem only occurs when using a higher-priority GPO to disable EFS.
Using the default domain GPO to accomplish this end causes no problems
whatsoever.
"Chris Largent" <chris.largent@spamisnotprofessionalpro-group.com> wrote in
message news:LNqdnat4MNwB65DcRVn-iw@giganews.com...
> Yep, this was the fundamental problem (i.e, incorrect Domain Controller
DNS
> configuration.) Subsequent to my posted corrections, my "Disable EFS"
> custom GPO is now working perfectly.
>
> Thanks again Steve!
>
> "Chris Largent" <chris.largent@spamisnotprofessionalpro-group.com> wrote
in
> message news:XfSdnThyBulJIZrcRVn-hA@giganews.com...
> > Steve, I think you hit the nail on the head. I think you may be correct
> > that my "EFS/Group Policy" issue was just a symptom of the problem, and
> the
> > actual problem was my DNS infrastructure configuration.
> >
> > In my case, both server A and server B pointed at themselves as the
> > "primary" DNS server. I also had the FSMO roles assigned to these two
> > domain controllers in a haphazard way (but I think the core problem was
> the
> > "primary" DNS misconfiguration.)
> >
> > So based on your prompting, and based on a few Microsoft knowledgebase
> > articles, I performed the following reconfiguration:
> >
> > 0) I didn't have to do anything with respect to my ISP's DNS servers.
> They
> > were already configured as just "forwarders".
> >
> > 1) I reconfigured my FSMO role placement. (An insignificant step, but
I
> > did it anyway.)
> >
> > (see article 223346)
> >
>
http://support.microsoft.com/default.aspx?scid=kb;en-us;223346&Product=win2000
> >
> > 2) I reconfigured my two domain controllers to point at only server A
as
> > "primary". Furthermore, on server A, I removed server B as a secondary.
> > Restated, server A now has NO secondary DNS configured.
> >
> > (see article 825036)
> >
>
http://support.microsoft.com/default.aspx?scid=kb;en-us;825036&Product=win2000
> >
> > 3) On server B, I removed itself as secondary. Restated, server B now
> has
> > NO secondary DNS configured. I'm sure this is a debatable step, but not
> > being an expert, I'm following the Microsoft knowledgebase article.
> Anybody
> > feel free to chime in.
> >
> > (see article 275278)
> >
>
http://support.microsoft.com/default.aspx?scid=kb;en-us;275278&Product=win2000
> >
> > 4) I updated my DHCP server configuration so that it hands out server A
> as
> > 'primary' and server B as 'secondary'.
> >
> > I won't have time to test this updated configuration with my "Disable
EFS"
> > GPO for a few days, but I'll attempt and post the outcome!
> >
> > "Steven L Umbach" <n9rou@n0-spam-for-me-comcast.net> wrote in message
> > news:vbwNc.169700$%_6.46028@attbi_s01...
> > > Your error points to possibly a dns misconfiguration which is the
number
> > one reason
> > > for AD problems. When you configure AD the first domain controller in
> the
> > domain must
> > > point to itself as it's preferred dns server in tcp/ip properties and
> > additional
> > > domain controllers need to point to the first domain controller [first
> in
> > the list]
> > > and themselves as their preferred dns servers. Then domain computers
> must
> > point ONLY
> > > to a W2K domain controller with the AD dns zone for the domain [they
all
> > do by
> > > default]. Never list an ISP dns server in the tcp/ip properties of any
> > domain
> > > computer. The support tools netdiag and dcdiag can be used to check
for
> > proper domain
> > > configuration with dcdiag reserved for domain controllers. If you
change
> > dns config
> > > on a domain controller run netdiag /fix and then restart netlogon
> service
> > on it and
> > > view Event Viewer for problems.
> > >
> > > What may have happened is that there was a replication problem with
the
> > new policy
> > > due to a dns lookup failure. You can also check on GPO replication
using
> > the gpotool
> > > and the replmon resource kit tool. Gpotool is quick and easy and will
> > report
> > > mismatches in policy between active domain controllers. The links
below
> > may
> > > help. --- Steve
> > >
> > >
http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B291382
> > >
> >
>
http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/gpotool-o.asp
> > >
> > > "Chris Largent" <chris.largent@spamisnotprofessionalpro-group.com>
wrote
> > in message
> > > news:4ZmdnYFakM39QZjcRVn-jw@giganews.com...
> > > > I have two domain controllers, A & B...
> > > >
> > > > A = Windows 2000 Server; PDC; DNS ('secondary' designation; Active
> > Directory
> > > > integrated mode)
> > > > B = Windows Server 2003; DNS ('primary' designation; AD integrated
> mode)
> > > > domain functional level = "Native 2000"
> > > >
> > > > I wanted to disable EFS (Encrypting File System) across the entire
> > domain.
> > > > Of course, none of the Microsoft knowledgebase articles EXPLICITLY
> > discuss a
> > > > MIXED environment of '2000 Server' and 'Server 2003'...
> > > >
> > > > I have never messed with Group Policy before, so only the domain's
> > default
> > > > Group Policy Object (GPO) existed. On server 'A', I created a brand
> new
> > > > GPO, moved it up in priority (above the default GPO), and followed
> > Microsoft
> > > > article 222022 (for 2000 Server.) I then let that new GPO
replicate,
> > and
> > > > subsequently followed Microsoft article 324897 (for Server 2003) on
> > server
> > > > 'B'. I made no other changes to the new GPO, so theoretically, all
> > other
> > > > policies within this new GPO were "not defined", and thus should not
> > have
> > > > overrided anything crazy in the default GPO (so I would think...)
> > > >
> > > > After this, everything got squirrelly, and I traced it down to
> something
> > > > related to DNS. On server 'A', the following was logged in the
> > Application
> > > > Event Log:
> > > >
> > > > Source = Userenv
> > > > EventID = 1000
> > > > Description = Windows cannot obtain the domain controller name for
> your
> > > > computer network. Return value (2146).
> > > >
> > > > After I disabled the new GPO, the domain cleared itself up. ...Now,
> > when I
> > > > make the 'disable EFS' modifications DIRECTLY to the DEFAULT GPO, my
> > domain
> > > > behaves properly, and EFS is truly disabled on a domain-wide basis.
> > > >
> > > > Can any gurus out there shed light on why my seemingly simple,
> > > > higher-priority GPO failed and caused the AD-DNS to fizzle out?
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Facebook
Twitter
Instagram