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

Comments

Popular posts from this blog

how to retrieve your ip address with powershell...

update: this is how it’s performed in powershell v3 as demonstrated here.(get-netadapter | get-netipaddress | ? addressfamily -eq'IPv4').ipaddress update: this is by far the easiest.PS C:\temp> (gwmi Win32_NetworkAdapterConfiguration | ? { $_.IPAddress -ne $null }).ipaddress
192.168.1.101
are you laughing yet?  i know you probably find this topic amusing.  it's really interesting though.  whenever you get over it, i'll do this in the standard cmd.exe interpreter and then in powershell to show you what kind of coolness powershell does.done?  okay, good.  this is an interpretation of a demo that bob wells did at our smug meeting.  hope you like it.i should tell you, it's not as simple as the title would lead you to believe.  i like doing that little slight-of-hand thing since it gives the impression that i'm painting a very easy target on my back for your criticism (though it's probably true in other ways)!  the idea is that we want to retrieve just the ip ad…

understanding the “ad op master is inconsistent” alert

i use the term “understanding” loosely.  this is by far no definitive guide on this particular alert, just a few things i have picked up in my attempt to understand it.let’s look at the context of the alert:The Domain Controller's Op Master is inconsitent. See additional alerts for details.
first of all, it gives very little information.  the only particularly useful detail is that it indicates which server is having the issue.  other than that, just a spelling error as there are no additional critical alerts to look at for details.this rule, as you know, comes from a sealed mp.  therefore, we can’t modify anything in it except the overrides.  the couple i’ve tinkered with are:interval (sec) log success event to begin with, interval (sec) is just set way too high.  the default is 60 seconds.  why on earth would anyone want to know that your op master consistency may be off, every minute?  actually, i could think of a few reasons, but really, it’s overkill.  the way the script works…

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.DETECTIONstatus messagestake 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 material to …