C
Christopher Hill
As you may or may not be aware, a few people are having
problems with
Group Policy and/or DFS when they upgrade their existing
Windows 2000
domains to Windows Server 2003. The following is the
solution to this
problem for you to act upon:
--
On performing the upgrade, some people receive group
policy processing
errors on computers that look like the following:
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1058
Date: 27/10/2003
Time: 15:07:37
User: NT AUTHORITY\SYSTEM
Computer: ADM01
Description:
Windows cannot access the file gpt.ini for GPO
cn={31B2F340-016D-11D2-945F-
00C04FB984F9},cn=policies,cn=system,DC=crgs,DC=local.
The file must be present at the location
<\\crgs.local\sysvol\crgs.local\Policies\{31B2F340-016D-
11D2-945F-00C04FB984F9}\gpt.ini>.
(The system cannot find the file specified. ). Group
Policy processing
aborted.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1030
Date: 27/10/2003
Time: 15:07:37
User: NT AUTHORITY\SYSTEM
Computer: ADM01
Description:
Windows cannot query for the list of Group Policy objects.
A message
that describes the reason for this was previously logged
by the policy
engine.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Others have problems accessing domain DFS shares, with an
error such
as:
'Configuration information could not be read from the
domain
controller, either because the machine is unavailable or
access is
denied'
--
I experienced these problems myself and I eventually
worked out that
it is all to do with the fact that under Windows Server
2003 domain
controllers (but not member servers) have the 'Microsoft
network
server: Digitally sign communications (always)' security
option
enabled by default.
The side effects of this change are documented in the
following page:
http://www.microsoft.com/technet/treeview/default.asp?
url=/technet/prodtechnol/windowsserver2003/proddocs/deployg
uide/dssbe_upnt_huxa.asp
but unfortunately one side-effect has not been taken into
account.
Many system administrators have experienced problems with
the SMB
signing feature of Windows 2000 causing slow network
access and
causing Word and other applications to hang when combined
with Windows
XP SP1.
These problems are documented in:
http://support.microsoft.com/default.aspx?scid=kb;EN-
US;810907
and a hotfix available.
However, many system administrators have taken matters
into their own
hands and disabled SMB signing across the network with
Group Policy,
as I did. They followed instructions in guides like this
one:
http://asia.cnet.com/itmanager/netadmin/0,39006400,39108281
,00.htm
to disable ***all four*** 'Microsoft network server'
signing settings.
However this causes a problem when the upgrade to Windows
Server 2003
occurs. Because the 'Microsoft network server: Digitally
sign
communications (if client agrees)' and 'Microsoft network
client:
Digitally sign communications (if server agrees)' options
are
DISABLED, it is impossible for any clients with these
settings to
connect to a Windows Server 2003 domain controller in the
default
configuration. The server REQUIRES signed packets - the
clients REFUSE
signed packets - so no channel can be established.
This breaks Group Policy and domain DFS links, both of
which (it
appears) require SMB communication with the domain
controller.
The problem goes even further though - as because many
people used
Group Policy to distribute the SMB signing changes, the
only way to
*reverse* the changes (without changing the registry) is
also through
Group Policy - and that is broken!
--
THEREFORE the solution to the problem is this:
1) Disable the 'Microsoft network server: Digitally sign
communications (always)' option on the Windows Server 2003
computer.
You can do this using the Local Security Settings admin
tools option.
However, if before the 2K3 server upgrade your domain
controller had
this setting set with Group Policy, you might have
problems. If you
do, then change the registry key directly on the domain
controller -
the registry key is:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanMan
Server\Parameters
RequireSecuritySignature (DWORD value, set it to 0 to
disable the
option)
2) Change your group policy object that disabled SMB
signing to only
have the 'Microsoft network server: Digitally sign
communications
(always)' and ''Microsoft network client: Digitally sign
communications (always)' disabled, if you still require
it. DO NOT SET
THE 'if client agrees' OR 'if server agrees' OPTIONS TO
DISABLED. It's
not necessary if you're applying this to all the computers
in your
domain.
3) If you want to enable the 'Microsoft network server:
Digitally sign
communications (always)' option again afterwards, only do
so once you
KNOW that all of the clients have received the update from
Step 2
(yes, this will mean you'll have to make sure they do a
group policy
refresh with secedit or gpupdate). When you re-enable this
option any
clients that still have 'if server agrees' set to DISABLED
will not be
able to talk to that server.
I hope this illuminates and helps some people.
problems with
Group Policy and/or DFS when they upgrade their existing
Windows 2000
domains to Windows Server 2003. The following is the
solution to this
problem for you to act upon:
--
On performing the upgrade, some people receive group
policy processing
errors on computers that look like the following:
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1058
Date: 27/10/2003
Time: 15:07:37
User: NT AUTHORITY\SYSTEM
Computer: ADM01
Description:
Windows cannot access the file gpt.ini for GPO
cn={31B2F340-016D-11D2-945F-
00C04FB984F9},cn=policies,cn=system,DC=crgs,DC=local.
The file must be present at the location
<\\crgs.local\sysvol\crgs.local\Policies\{31B2F340-016D-
11D2-945F-00C04FB984F9}\gpt.ini>.
(The system cannot find the file specified. ). Group
Policy processing
aborted.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1030
Date: 27/10/2003
Time: 15:07:37
User: NT AUTHORITY\SYSTEM
Computer: ADM01
Description:
Windows cannot query for the list of Group Policy objects.
A message
that describes the reason for this was previously logged
by the policy
engine.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Others have problems accessing domain DFS shares, with an
error such
as:
'Configuration information could not be read from the
domain
controller, either because the machine is unavailable or
access is
denied'
--
I experienced these problems myself and I eventually
worked out that
it is all to do with the fact that under Windows Server
2003 domain
controllers (but not member servers) have the 'Microsoft
network
server: Digitally sign communications (always)' security
option
enabled by default.
The side effects of this change are documented in the
following page:
http://www.microsoft.com/technet/treeview/default.asp?
url=/technet/prodtechnol/windowsserver2003/proddocs/deployg
uide/dssbe_upnt_huxa.asp
but unfortunately one side-effect has not been taken into
account.
Many system administrators have experienced problems with
the SMB
signing feature of Windows 2000 causing slow network
access and
causing Word and other applications to hang when combined
with Windows
XP SP1.
These problems are documented in:
http://support.microsoft.com/default.aspx?scid=kb;EN-
US;810907
and a hotfix available.
However, many system administrators have taken matters
into their own
hands and disabled SMB signing across the network with
Group Policy,
as I did. They followed instructions in guides like this
one:
http://asia.cnet.com/itmanager/netadmin/0,39006400,39108281
,00.htm
to disable ***all four*** 'Microsoft network server'
signing settings.
However this causes a problem when the upgrade to Windows
Server 2003
occurs. Because the 'Microsoft network server: Digitally
sign
communications (if client agrees)' and 'Microsoft network
client:
Digitally sign communications (if server agrees)' options
are
DISABLED, it is impossible for any clients with these
settings to
connect to a Windows Server 2003 domain controller in the
default
configuration. The server REQUIRES signed packets - the
clients REFUSE
signed packets - so no channel can be established.
This breaks Group Policy and domain DFS links, both of
which (it
appears) require SMB communication with the domain
controller.
The problem goes even further though - as because many
people used
Group Policy to distribute the SMB signing changes, the
only way to
*reverse* the changes (without changing the registry) is
also through
Group Policy - and that is broken!
--
THEREFORE the solution to the problem is this:
1) Disable the 'Microsoft network server: Digitally sign
communications (always)' option on the Windows Server 2003
computer.
You can do this using the Local Security Settings admin
tools option.
However, if before the 2K3 server upgrade your domain
controller had
this setting set with Group Policy, you might have
problems. If you
do, then change the registry key directly on the domain
controller -
the registry key is:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanMan
Server\Parameters
RequireSecuritySignature (DWORD value, set it to 0 to
disable the
option)
2) Change your group policy object that disabled SMB
signing to only
have the 'Microsoft network server: Digitally sign
communications
(always)' and ''Microsoft network client: Digitally sign
communications (always)' disabled, if you still require
it. DO NOT SET
THE 'if client agrees' OR 'if server agrees' OPTIONS TO
DISABLED. It's
not necessary if you're applying this to all the computers
in your
domain.
3) If you want to enable the 'Microsoft network server:
Digitally sign
communications (always)' option again afterwards, only do
so once you
KNOW that all of the clients have received the update from
Step 2
(yes, this will mean you'll have to make sure they do a
group policy
refresh with secedit or gpupdate). When you re-enable this
option any
clients that still have 'if server agrees' set to DISABLED
will not be
able to talk to that server.
I hope this illuminates and helps some people.