Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Applying Workaround in KB899148

48 views
Skip to first unread message

bsbm525

unread,
Oct 2, 2009, 3:54:09 PM10/2/09
to
Using Exchange 2003 SP1 on a Windows 2003 server & planning on applying the
'method 2' workaround in KB899148 after installing SP2 for Exchange.
See below:

After you apply Windows Server 2003 SP2, you must follow these steps to
modify the registry:

1. Click Start, click Run, type regedit, and then click OK
2. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Rpc
3. Click the Edit menu, point to New, and then click DWORD Value.
4. Type Server2003NegotiateDisable as the name of the new DWORD Value
5. Right-click Server2003NegotiateDisable, and then click Modify.
6. In the Value Data box, type 1, and then click OK.

Note This setting disables the bind time negotiation and the multiple
transfer syntax negotiation.

7. Exit Registry Editor, and then restart the computer.
8. After the firewalls and the VPN devices are compatible with RPC on the
computer, set the value for the Server2003NegotiateDisable registry entry to
0. Then, restart the computer.

My question is in regards to step #8.

Am I supposed to set the registry entry back to 0 on the Exchange server
only or on my Vista client computer as well?

Also, am I supposed to set the entry back to 0 after I confirm I can connect
to my mailbox using Outlook 2007 using my Cisco VPN?

Thanks....


Rich Matheisen [MVP]

unread,
Oct 2, 2009, 11:36:39 PM10/2/09
to
On Fri, 2 Oct 2009 12:54:09 -0700, bsbm525
<bsb...@discussions.microsoft.com> wrote:

[ snip ]

>Am I supposed to set the registry entry back to 0 on the Exchange server
>only or on my Vista client computer as well?

Set it to zero on the machines where you set it to one -- AFTER you've
verified that the RPC filters on the routers/firewalls will allow the
traffic to pass.

>Also, am I supposed to set the entry back to 0 after I confirm I can connect
>to my mailbox using Outlook 2007 using my Cisco VPN?

You'd have to set it to zero to confirm that you don't have the
prolem. Keeping it set to one is how you avoid using the features that
casue the problem.
---
Rich Matheisen
MCSE+I, Exchange MVP

bsbm525

unread,
Oct 2, 2009, 11:52:06 PM10/2/09
to
Thanks for your response.
However I just tried the workaround but no change.
I set Server2003NegotiateDisable to 1 on both my Vista client and Exchange
2003 Server (after installing SP2 first) and then restarted both.
After connecting my VPN I still cannot access my mailbox using Outlook 2007.
Any suggestions? Did I miss a step?

Rich Matheisen [MVP]

unread,
Oct 3, 2009, 1:10:32 PM10/3/09
to
On Fri, 2 Oct 2009 20:52:06 -0700, bsbm525
<bsb...@discussions.microsoft.com> wrote:

>Thanks for your response.
>However I just tried the workaround but no change.
>I set Server2003NegotiateDisable to 1 on both my Vista client and Exchange
>2003 Server (after installing SP2 first) and then restarted both.
>After connecting my VPN I still cannot access my mailbox using Outlook 2007.
>Any suggestions? Did I miss a step?

I guess the 1st question I'd ask is why you think that's your problem
and not something else? The 2nd questions would be "does it work if
you don't use VPN and use RPC-over-HTTPS?"

We've run into lots of different problems with different VPNs over the
years. Some are the VPN client, some are the carrier (usually
DSL/Cable). Most of them involve packet sizes. Different carriers/VPNs
add data to the packet that sometimes causes it to exceed the MTU.
That leads to fragmentation and all the problems with reassembly of
the original packet. We've also seen problem using Kerberos with UPD
and VPN (and sometime just with UPD if the security token is larger
than the negotiated packet size).

The 1st thing I'd try is forcing Kerberos to use TDP instead of TCP on
the client machine:
http://support.microsoft.com/kb/244474

If that doesn't work, try reducing the MTU on the client. To see if
you have a fragmentation problem you can use ping:

This should work:
ping <ip-address> -l 1472 -f

This should fail:
ping <ip-address> -l 1473 -f

If the ping with the packet size 1472 fails you'll have to reduce the
client's MTU size. Use "ping" with different packet sizes to figure
out what it should be.

bsbm525

unread,
Oct 6, 2009, 9:55:01 AM10/6/09
to
Thanks for the info. I have an open case with Exchange support and will also
try your suggestions.
0 new messages