Skip to main content

Preparing for the End of Windows Server 2003

It’s a little embarrassing, or maybe I should say lucky, that somehow I hadn’t the need to review the changes to the dynamic port range assignments. I say it that way because the range wasn’t something that recently changed. By recent, let’s call it 2012. No, in fact, it goes back to 2008. Microsoft changed the dynamic port range to comply with IANA recommendations effectively moving the range:

 

From

To

Old

1025

5000

New

49152

65535

 

SYMPTOMS

The troubles you’ll find with this kind of change usually won’t present itself until you try to restrict it somehow. This issue was noticed when domain controllers were upgraded to 2012. The version previous was 2003. :-|

The kinds of issues witnessed appeared all over the place, compounded with confusion since the issues weren’t well captured or documented during troubleshooting. Here’s what was seen along with the corresponding error messages:

  • Failure to connect to a share
    • Windows cannot access <share>
    • The trust relationship between this workstation and the primary domain failed
  • Failure to test secure channel
    • Access Denied
  • Failure to join a domain
    • The join operation was not successful. This could be because an existing computer account having name <myComputer> was previously created using a different set of credentials. Use a different computer name, or contact your administrator to remove any stale conflicting account. The error was: Access is denied.

Notably, netlogon.log would also show errors suggesting problems during the domain join such as:

10/03/2014 02:00:52:695 SamOpenUser on 564842 failed with 0xc0000022
10/03/2014 02:00:52:695 NetpManageMachineAccountWithSid: status of attempting to set password on <myDomainController> for <myComputer>: 0x5
10/03/2014 02:00:52:695 NetpJoinDomain: status of creating account: 0x5
10/03/2014 02:00:52:695 NetpJoinDomain: initiaing a rollback due to earlier errors

 

DIAGNOSTICS

Sometimes the quickest way to resolution is what some people assume to be the hardest. It’s important to get trace packets from both hosts at the same time. After that, the other trick is to read it. :o)

In this dump, you’ll see where EPM (endpoint mapper) negotiates to port 50445. After that, all hell breaks loose. Just kidding. In reality, you simply won’t see any of those packets reaching the destination port since the environment was configured to respect the old dynamic port range. (Never mind the IPs. I’m protecting the innocent.)

4846    4:12:03 AM 10/3/2014    62.5715595      svchost.exe     192.168.94.34   <myDomainController>  EPM     EPM:Request: ept_map: NDR, DRSR(DRSR) {E3514235-4B06-11D1-AB04-00C04FC2DCD2} v4.0, RPC v5, 0.0.0.0:135 (0x87) [DCE endpoint resolution(135)]    {MSRPC:857, TCP:856, IPv4:130}
4847    4:12:03 AM 10/3/2014    62.5721299      svchost.exe     <myDomainController>  192.168.94.34   EPM     EPM:Response: ept_map: NDR, DRSR(DRSR) {E3514235-4B06-11D1-AB04-00C04FC2DCD2} v4.0, RPC v5, 192.168.11.34:50445 (0xC50D) [50445]  {MSRPC:857, TCP:856, IPv4:130}
4848    4:12:03 AM 10/3/2014    62.5944302      svchost.exe     192.168.94.34   <myDomainController>  TCP     TCP:Flags=......S., SrcPort=65207, DstPort=50445, PayloadLen=0, Seq=3334272165, Ack=0, Win=8192 ( Negotiating scale factor 0x8 ) = 8192 {TCP:858, IPv4:130}
5010    4:12:06 AM 10/3/2014    65.5937718      svchost.exe     192.168.94.34   <myDomainController>  TCP     TCP:[SynReTransmit #4848]Flags=......S., SrcPort=65207, DstPort=50445, PayloadLen=0, Seq=3334272165, Ack=0, Win=8192 ( Negotiating scale factor 0x8 ) = 8192    {TCP:858, IPv4:130}
5380    4:12:12 AM 10/3/2014    71.5937519      svchost.exe     192.168.94.34   <myDomainController>  TCP     TCP:[SynReTransmit #4848]Flags=......S., SrcPort=65207, DstPort=50445, PayloadLen=0, Seq=3334272165, Ack=0, Win=8192 ( Negotiating scale factor 0x8 ) = 8192    {TCP:858, IPv4:130}

A quick, client-side port query would confirm that in fact, it cannot do anything over that port.

 

SUMMARY

In short, prepare for your transition away from 2003. I know many of you (myself included) still have things running on 2003. This is one you should look for and remediate wherever possible. Here’s a link to the article describing the default dynamic port range changes:

The default dynamic port range for TCP/IP has changed in Windows Vista and in Windows Server 2008

By the way, did you know you can run a packet trace from netsh? Oh yes, you can. Here’s a link to my blog post: Using netsh to Capture Packets

Labels:

Comments

Post a Comment

Popular posts from this blog

using preloadpkgonsite.exe to stage compressed copies to child site distribution points

UPDATE: john marcum sent me a kind email to let me know about a problem he ran into with preloadpkgonsite.exe in the new SCCM Toolkit V2 where under certain conditions, packages will not uncompress.  if you are using the v2 toolkit, PLEASE read this blog post before proceeding.   here’s a scenario that came up on the mssms@lists.myitforum.com mailing list. when confronted with a situation of large packages and wan links, it’s generally best to get the data to the other location without going over the wire. in this case, 75gb. :/ the “how” you get the files there is really not the most important thing to worry about. once they’re there and moved to the appropriate location, preloadpkgonsite.exe is required to install the compressed source files. once done, a status message goes back to the parent server which should stop the upstream server from copying the package source files over the wan to the child site. anyway, if it’s a relatively small amount of packages, you can
11 comments
more »

How to Identify Applications Using Your Domain Controller

Problem Everyone has been through it. We've all had to retire or replace a domain controller at some point in our checkered collective experiences. While AD provides very intelligent high availability, some applications are just plain dumb. They do not observe site awareness or participate in locating a domain controller. All they want is the name or IP of one domain controller which gets hardcoded in a configuration file somewhere, deeply embedded in some file folder or setting that you are never going to find. How do you look at a DC and decide which applications might be doing it? Packet trace? Logs? Shut it down and wait for screaming? It seems very tedious and nearly impossible. Potential Solution Obviously I wouldn't even bother posting this if I hadn't run across something interesting. :) I ran across something in draftcalled Domain Controller Isolation. Since it's in draft, I don't know that it's published yet. HOWEVER, the concept is based off
3 comments
more »

sccm: content hash fails to match

back in 2008, I wrote up a little thing about how distribution manager fails to send a package to a distribution point . even though a lot of what I wrote that for was the failure of packages to get delivered to child sites, the result was pretty much the same. when the client tries to run the advertisement with an old package, the result was a failure because of content mismatch. I went through an ordeal recently capturing these exact kinds of failures and corrected quite a number of problems with these packages. the resulting blog post is my effort to capture how these problems were resolved. if nothing else, it's a basic checklist of things you can use.   DETECTION status messages take a look at your status messages. this has to be the easiest way to determine where these problems exist. unfortunately, it requires that a client is already experiencing problems. there are client logs you can examine as well such as cas, but I wasn't even sure I was going to have enough m
3 comments
more »