Windows Server 2003 upgrade Group Policy and DFS problems - SMB Signing

From: Christopher Hill (minkus_at_ntlworld.com)
Date: 03/17/04 

Date: Wed, 17 Mar 2004 04:34:15 -0800

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.

Relevant Pages