Jan 26, 2015

Enabling the Windows 10 Calendar

Are you running the Windows 10 Technical Preview yet? If so, here’s a little refresh for the new calendar. The problem is, you might need to hack your registry to get it to show up.

Does your calendar look like this?



Try the registry hack to get it to look like this:



Here’s the hack:

  • Open the Registry Editor (regedit).
  • Head to this path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ImmersiveShell
  • Create a new DWORD (32-bit) Value entry.
  • Name it UseWin32TrayClockExperience.



That’s it!

Try click on the clock on your taskbar. You should now see the refreshed calendar. :)

Jan 13, 2015

Jump to Conclusions About Leap Seconds

What a better way to start off the new year than to write about the leap second. According to Wikipedia, the leap second system, designed to adjust for “irregularities in the Earth’s rate of rotation”, was introduced in 1972. Since that point, 25 leap seconds have been inserted to adjust the atomic time. Most recently, it occurred on June 30, 2012 at 23:59:60 UTC. That’s right. A leap second is displayed as :60.

Since time is the topic today, I was reading a blog post on this event as it pertains to Windows this morning and thought I’d share a few interesting points and observations:

  • In KB 909614 How the Windows Time service treats a leap second, the article seems to indicate that the Windows Time service does not do anything with the leap indicator. During this point, the NTP client will be a second faster than the atomic time which is resolved at the next time sync. The wording is a little confusing to decipher in my opinion.
  • Most applications cannot handle leap seconds since the time structure only allows a range of 00-59, not 60. Even when a leap second occurs, they are usually not sent to the application by the system clock.
  • Time drift happens all the time. If you’re a domain administrator (by trade, not your permissions1) then you know what I’m talking about since you have time drift with Kerberos is a pretty big deal. These drifts are corrected by a sync. From that perspective, leap seconds aren’t really treated any differently.
  • If you synchronize your Windows Time service with a GPS time source, note that the Time Service Department of the US Naval Observatory states the following: “GPS Time is NOT adjusted for leap seconds.”

Okay, cool. If time adjustments for leap second are cleared up on the next sync, then when does the next sync actually happen? Well, the answer is, I’m not sure. It’s not totally clear. It seems the behavior for stand-alone clients differ from those that are domain members. For stand-alone NTP clients, the value is every 7 days or 604,800 seconds.


Stand-Alone Client Behavior

Before I confuse things much further, let’s take a look at the registry to see what’s in there -- HKLM\SYSTEM\CurrentControlSet\services\W32Time. First thing to look at is the Parameters key. Here are some relevant things:

  • Type. If the type is set to NT5DS, congratulations, you are a domain member. You can skip this section.
  • NtpServer. This a space delimited set of time sync sources. Not only is host important, you need to make sure the appropriate a flags are set. Normally, it will be 0x9 which indicates a combination of Client + SpecialInterval.
    • 0x01 SpecialInterval
    • 0x02 UseAsFallbackOnly
    • 0x04 SymmetricActive
    • 0x08 Client

Switch over to the TimeProviders\NtpClient key. The SpecialPollInterval value is supposed to define how often your client will sync. I’ve read where someone did not get the desired result. Maybe the NtpServer value wasn’t set correctly since it wasn’t mentioned in the post.

  • SpecialPollInterval. Define in seconds how often to sync with time sources listed in NtpServer.


Domain Client Behavior

It’s hard to find any new data on this as the newest thing I can find dates back to a Windows 2000 article. Remember the Type value I mentioned earlier? If it’s set to NT5DS, it should act as the article indicates which means typically, the client will sync every 45 minutes.



Not the first time I’ve been wrong on this topic especially considering I haven’t validated the stand-alone process yet. It gets confusing because of the behavioral differences in stand-alone versus domain-joined. If you find some good info, please comment!

1 If you’re not a domain administrator by trade and have domain administrator permissions, I need to speak to your real domain administrator.

Jan 2, 2015

Top 20 of 2014

Hello everyone. These are the 20 most frequented views on my blog last year. I’m really surprised how many old posts continue to get visited. I guess some things in technology change slower than others. I’m guilty of running some pretty old platforms (by today’s standards.) New year resolution?

  1. Understanding the “AD Op Master is inconsistent” Alert
  2. How to Retrieve Your IP Address with PowerShell
  3. SCCM: Content Hash Fails to Match
  4. How to Use Dropbox to Synchronize Windows 7 Sticky Notes
  5. SCCM: Client Stuck Downloading Package with BIT*.TMP Files in Cache Directory
  6. Search Programs and Files No Longer Works in Windows 7 (Only Shows Headers)
  7. Using PowerShell to List Active Directory Trusts
  8. “Get Computer/IP Status” Activity Throws Raw Socket Error
  9. SCCM: Custom Data Discovery Records (DDRs) Using PowerShell
  10. SCCM: Integrating Dell Warranty Data Into ConfigMgr
  11. SCCM Clients Fail to Apply Policy
  12. SCCM: The Required Permissions for Creating Collections
  13. SCCM: Computers with Names Greater Than 15 Characters
  14. List Active Directory Subnets with PowerShell
  15. SSRS: The Variable Name Has Already Been Declared -- When Working with Temp Tables
  16. EXCEL: My First Use of Power Query (And I Love It)
  17. Using PreloadPkgOnSite.exe to Stage Compressed Copies to Child Site Distribution Points
  18. SCCM: Top Console Users Reports
  19. Executing Batch Files Remotely with PSExec
  20. List Domain Controllers with PowerShell

And that’s it! Hope you all have a spectacular 2015.

Dec 5, 2014

PowerShell: Retrieve site location of computer object

This is a nice find that I am cataloging from Shay Levy.

You can get the site location of a computer if you run this PS script on the computer itself.



It’s effectively the same as using NLTEST.

nltest /dsgetsite


I had intended to use it with Compliance Settings but the compliance rules limitations made it a impractical. Still going to be useful for other stuff. If you want remote options, read more about it at the original post: #PSTip Get the AD site name of a computer.

Oct 27, 2014

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:












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



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   <myDomainController>  EPM     EPM:Request: ept_map: NDR, DRSR(DRSR) {E3514235-4B06-11D1-AB04-00C04FC2DCD2} v4.0, RPC v5, (0x87) [DCE endpoint resolution(135)]    {MSRPC:857, TCP:856, IPv4:130}
4847    4:12:03 AM 10/3/2014    62.5721299      svchost.exe     <myDomainController>   EPM     EPM:Response: ept_map: NDR, DRSR(DRSR) {E3514235-4B06-11D1-AB04-00C04FC2DCD2} v4.0, RPC v5, (0xC50D) [50445]  {MSRPC:857, TCP:856, IPv4:130}
4848    4:12:03 AM 10/3/2014    62.5944302      svchost.exe   <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   <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   <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.



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