Today's Thoughts on Windows 8.1 (Will Do Server 2012 R2 Next)

Guten abend!

So thankfully, Microsoft reversed their earlier decision to not release Windows 8.1 and Server 2012 R2 RTM on TechNet or MSDN until October 18th. Both products popped up on TechNet a few days ago. So, I downloaded both and have been playing with them in my lab the past few days. (Which is likely the last good thing I will be able to get from TechNet.  Rest in peace, you final bastion of good will from Microsoft to IT professionals.)

Windows 8.1 has gone onto the following test machine:

  • Intel Core i5-2500k
  • 16GB RAM
  • 256GB Samsung SSD
  • NVidia GTX 670 2GB

Needless to say, it screams. My experience has been that you will typically have a better time with Win 8 if you set it up with your Microsoft Live ID from the beginning, and not a domain account. In fact, it's almost impossible to install Windows 8.1 with anything other than your Microsoft Live ID. (Although you're free to join a domain later, after the install. But good luck installing with a local account.) I would say that this will be a barrier for Windows 8 adoption in the enterprise, however, the actual Win 8.1 Enterprise SKU has not been released yet, so the installer for that edition should be tweaked for easier installation in an AD domain in an enterprise environment. (And I admittedly have not even tried custom deployable images as you would with an enterprise environment.)

That looks weird.

But in a home setting, the reason I think it's awesome to go ahead and use your Live ID to install Windows 8.1 is because:

  • Your Skydrive sets itself up. It's already there waiting for you. It's integrated into Explorer already, and the coolest part is it initially takes up no room on your hard drive. It all stays online but browsable from within Explorer, and you only pull a file down from the cloud when you open it. But if you have some need to have it available offline? Just right-click the file, folder, or your entire Skydrive and choose "Make available offline" and it will all be downloaded locally. If you used Skydrive before 8.1, you should love this improvement. If you did not use Skydrive before 8.1 then you may find that this added feature only gets in the way. 
  • All your OS settings from Windows 8 are synchronized and brought into 8.1, even if you performed a clean install of 8.1. As soon as the installation finished, I landed on a Windows desktop and my wallpaper is already what I had on my last PC, because the wallpaper was stored on Skydrive. Furthermore, all my settings like 'folder view settings' were automatically sucked into the new installation as well. Ever since Windows 95, every time I would install the OS on a new machine, the first thing I did was go to the folder view settings and uncheck the "Hide File Extensions" option. I always hated that Windows would hide the file extension of files. Well, now that setting stays with me on every Win 8 machine I move to and I no longer have to worry about it.
  • IE11 seems great so far. Very fast, although, that could also be attributed to my beefy hardware. However, I have experienced one compatibility problem so far with IE11. I know that the user agent string for one thing changed dramatically in IE11. But in a pinch, hit F12 for the developer tools and you can emulate any down-level version of IE that you need. No big deal. I'll resist the urge to rant against web developers here.
  • (Though seriously, web developers, if you're listening, you are ruining the web.)
  • Boot to desktop and the ability to show your desktop wallpaper as your Start Screen background are welcome features. The resurrection of the classic Start Button on the taskbar, however, I don't care about one way or the other. I never really missed the old Start Menu from old versions of Windows. I pretty much don't care about the 'Modern,' 'Metro' interface either way, but I'm not bitter about it, because I know it wasn't made for me. It was made for phones and tablets. I have a desktop PC, and as such, I have no need for the Modern UI. End of story. Use what works for you. The OS now has a new feature now that I'm not really interested in, but who cares, the rest of the underlying OS is still there, and it's still good.
  • The Remote Server Administration Tools for Win 8.1 Preview installs on and works in Win 8.1 RTM, which I am using to set up a full Server 2012 R2 lab environment, which I shall talk about shortly in an upcoming blog post!

Powershell RemoteSigned and AllSigned Policies, Revisited

A while back I talked about Powershell signing policies here.  Today I'm revisiting them.

Enabling script signing is generally a good idea for production environments. Things like script signing policies, using Windows Firewall, etc., all add up to provide a more thorough defense-in-depth strategy.

On the other hand, one negative side-effect that I've seen from enforcing Powershell signing policies is that it breaks the Best Practices Analyzers in Windows Server, since the BPAs apparently use scripts that are unsigned. Which is strange, since Microsoft is usually very good about signing everything that they release. I assume that they've since fixed that.

I'd consider the biggest obstacle to using only signed Powershell scripts to be one of discipline. But maybe that in itself is a good thing - if only the admins and engineers who are disciplined enough to put their digital signature on something are allowed to run PS scripts in production, perhaps that will cut down on the incidents of wild cowboys running ill-prepared scripts in your environment, or making a quick change on the fly to an important production script, etc. Could you imagine having to re-sign your script every time you changed a single line? That seems like the perfect way to encourage the behavior that scripts are first perfected in a lab, and only brought to production once they're fully baked and signed.

The next obstacle is getting everyone their own code signing certificate. This means you either need to spend some money getting a boat-load of certs from a public CA for all your employees, or you need to maintain your own PKI in your own Active Directory forest(s) for internal-use-only certificates.  This part alone is going to disqualify many organizations. Very rare is the organization that cares about properly signing things in their IT infrastructure.  Even rarer is the organization that actually does it, as opposed to just saying they want everything to be properly signed.  "It's just too much hassle... and now you're asking me to sign all my scripts, too?"

I also want to reinforce this point: Like UAC, Powershell script execution policies are not meant to be relied upon as a strong security measure. Microsoft does not tout them as such. They're meant to prevent you from making mistakes and doing things on accident. Things like UAC and PS script execution policies will keep honest people honest and non-administrators from tearing stuff up.  An AllSigned execution policy can also thwart unsophisticated attempts to compromise your security by preventing things such as modifying your PS profile without your knowledge to execute malicious code the next time you launch Powershell. But execution policies are no silver bullet. They are simply one more thin layer in your overall security onion.

So now let's play Devil's advocate. We already know the RemoteSigned policy should be a breeze to bypass just by clearing the Zone.Identifier alternate NTFS data stream. How do we bypass an Allsigned policy?

PS C:\> .\script.ps1
.\script.ps1 : File C:\script.ps1 cannot be loaded. The file C:\script.ps1 is not digitally signed. The script will not execute on the system.

Script won't execute?  Do your administrator's script execution policies get you down?  No problem:

  • Open Notepad.
  • Paste the following line into Notepad:
Powershell.exe -NoProfile -Command "Powershell.exe -NoProfile -EncodedCommand ([Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes((Get-Content %1 | %% {$_} | Out-String))))"
  • Save the file as bypass.bat.
  • Run your script by passing it as a parameter to bypass.bat.

PS C:\> .\bypass.bat .\script.ps1

... And congratulations, you just bypassed Powershell's execution policy as a non-elevated user.

So in conclusion, even after showing you how easy it is to bypass the AllSigned execution policy, I still recommend that good execution policies be enforced in production environments. Powershell execution policies are not meant to foil hackers.

  1. They're meant to be a safeguard against well-intentioned admins accidentally running scripts that cause unintended consequences.
  2. They verify the authenticity of a script. We know who wrote it and we know that it has not been altered since they signed it.
  3. They encourage good behavior by making it difficult for admins and engineers to lackadaisically run scripts that could damage a sensitive environment.

Microsoft MCM and MCA Certifications Are Dead

First they trash TechNet subscriptions, and now I'm hearing that Microsoft Certified Master and Architect certifications are officially dying now as well. (Note: the following email was not sent to me. It came from this guy.) 

We are contacting you to let you know we are making a change to the Microsoft Certified Master, Microsoft Certified Solutions Master, and Microsoft Certified Architect certifications. As technology changes so do Microsoft certifications and as such, we are continuing to evolve the Microsoft certification program. Microsoft will no longer offer Masters and Architect level training rotations and will be retiring the Masters level certification exams as of October 1, 2013. The IT industry is changing rapidly and we will continue to evaluate the certification and training needs of the industry to determine if there's a different certification needed for the pinnacle of our program.

As a Microsoft Certified Master, Microsoft Certified Solutions Master, or Microsoft Certified Architect, you have earned one of the highest certifications available through the Microsoft Certification program. Although individuals will no longer be able to earn these certifications, you will continue to hold the credential and you will not be required to recertify your credential in the future. You will continue to have access to the logos through the MCP site, and your certifications will continue to show in the appropriate section of your transcript, according to Microsoft technology retirement dates. If you are a Charter Member, you will continue to hold the Charter Member designation on your transcript.

Also as a Microsoft Certified Master, Microsoft Certified Solutions Master, or Microsoft Certified Architect, you are a member of an exclusive, highly technical community and you've told us this community is one of the biggest benefits of your certification. We encourage you to stay connected with your peers through the main community distribution lists. Although we won't be adding more people to this community, you continue to be a valued member of it. Over time, Microsoft plans to transition the distribution lists to the community, and, with your consent, will include your information so that it can continue to be a valuable resource for your ongoing technical discussions.

Within the coming weeks, you will receive invitations to an updated community site. This community site will require you to sign in with a Microsoft Account and will replace the need for a Microsoft Partner account as is required today. From this site, you will be able to manage service requests for the Masters and Architects communities – such as ordering welcome kits and managing your contact information for the distribution lists and directory - and accessing training rotation and other community content (if applicable).

If you have not ordered your Welcome Kit, the last day to do so is October 31, 2013. To order your Welcome Kit, please contact the Advanced Cert team at advcert@microsoft.com.

We thank you for your commitment to Microsoft technologies.

This is extraordinarily depressing for me, as Microsoft Certified Master certification has been one of my biggest goals for the past three years. And now that's no longer a possibility.

I don't know why Microsoft would make such a decision, or if there will ever be a new equivalent certification to take the place of the MCM and MCA.

Microsoft, many of us do not understand your recent decisions that appear to be squarely anti-IT Pro. Microsoft Certified Masters and Architects were your strongest supporters and evangelists. They help advocate your products to customers and drive sales for you, Microsoft.  They spent the time and effort on that Masters or Architect certification because of a sincere passion for your products. I can't think of any other reason for you to make this decision unless you just don't want highly skilled and trained people advocating your products.

There are pockets of activism showing up already.  Here is a petition of sorts on Microsoft Connect that you can participate in. If you find any other similar petitions, please let me know.

SRV Record for NTP? In *MY* Active Directory?

Howdy fellow IT goons. I am probably not going to talk about Powershell today... but no promises.

Good ole' RFC 2782, the great fireside reading that it is, spells out the concept behind DNS SRV records and using them to locate services within a domain. The Microsoft article "How DNS Support for Active Directory Works", which is also more than just a heart-warming story but is also required reading if you're a Windows admin, mentions that Active Directory is pretty much, more or less, compliant with the aforementioned RFC:

"When a domain controller is added to a forest, a DNS zone hosted on a DNS server is updated with the Locator DNS resource records for that domain controller. For this reason, the DNS zone must allow dynamic updates (RFC 2136), and the DNS server hosting that zone must support the SRV resource records (RFC 2782) to advertise the Active Directory directory service."

It goes _<service>._<protocol>.domain.com, so if I wanted to locate LDAP services in a domain I'd issue a DNS query for _ldap._tcp.domain.com, or if I wanted to find Kerberos service I'd do _kerberos._tcp.domain.com.

But no one ever said that Active Directory uses every type of SRV there is by default. Not even close. Take NTP, Network Time Protocol, as an example.  Given the above logic I might issue a DNS query for _ntp._udp.domain.com, searching for NTP time service in that domain. Assuming I'm in a Microsoft Active Directory domain, odds are that I will not find it.

An SRV record is not created by default for the NTP service.  This is because Windows clients connecting to an AD domain already know to use domain controllers for time service in an AD domain, and the domain controllers already have their own SRV records, so separate NTP records would be redundant and unnecessary.

In fact, the only Microsoft-centric scenario I know of where the SRV record _ntp._udp.domain.com comes in to play is smart phones and devices using Microsoft Office Communicator or Lync - and even then it's optional since they'll fail back to time.windows.com if the SRV record is not found. You can find those examples here and here. If you know of any other situations where Windows-based applications use such an SRV record, please let me know.

But maybe you have a heterogeneous IT environment and you may want to add these records for yourself in order to support Unix/Linux clients and their applications that are making such DNS queries.  It's very easy:

  • Open the DNS Manager console/MMC snap-in.
  • Drill down into your Forward Lookup Zones.
  • Locate the _udp subdomain, since the NTP service operates over the UDP protocol.
  • You should see a list of _kerberos and _kpasswd SRV records there already, that represent the domain controllers currently in your domain.
  • Right-click in that white space and choose "Other New Records..."
  • Select "Service Location (SRV)" from the list.
  • Configure your new record like this screenshot:

SRV record

Mind the underscores, and notice the trailing period at the end of your domain name. You will probably want to add one of these for each domain controller you have, and you can play around with the weights and priorities however you like. NTP uses port 123 of course. There will be some options in the drop down list that they give you as examples. Don't confuse it with _nntp, unless you host the News Network Transfer service in your domain too.

Powershell: Set-StrictMode -Version Latest

Set-StrictMode is a wonderful Cmdlet that you should use in every script you write.  It will save you hours of debugging and frustration from things like fat-fingered variable and property names.  Here is what version 2 of Set-StrictMode does:

-- Prohibits references to uninitialized variables (including uninitialized variables in strings).
-- Prohibits references to non-existent properties of an object.
-- Prohibits function calls that use the syntax for calling methods.
-- Prohibits a variable without a name (${}).

If you apply Set-StrictMode to some of your old scripts, you'll be surprised at how many new errors it will throw at you. This is good though, because it encourages you to write safer, cleaner code with less bugs.  Number 2 on the list above was giving me fits today, however.  Let me give you an example.

$Users = Get-ADUser -Filter * -Properties *

Now let's say that I am interested in the EmployeeId attribute of the users. Even though I specified -Properties *, the user objects in the collection may or may not have a property called EmployeeId. The user object will not have an EmployeeId property that is blank or null.  If the attribute is not populated in Active Directory, the Cmdlet omits the property entirely.  So in a script without Strict Mode, I could just do

Foreach($User In $Users) { If($User.EmployeeId) { ... } }

And it would function as expected, running the code block if the user had an EmployeeId, and skip it otherwise. But with Strict Mode, you'll see a lot of this:

Property 'EmployeeId' cannot be found on this object; make sure it exists.
At line:1 char:9
+ $User. <<<< EmployeeId
    + CategoryInfo          : InvalidOperation: (.:OperatorToken) [], RuntimeException
    + FullyQualifiedErrorId : PropertyNotFoundStrict

Even if I did

$Users = Get-ADUser -Filter { EmployeeId -NE $Null } -Properties *

or

$Users = Get-ADUser -Filter * -Properties * | Where-Object { $_.EmployeeId -NE $Null }

I would still get the errors when running through the Foreach loop, even though that should have given me only the users with EmployeeIDs. So I need a way to test for the existence of an object property, rather than just assuming that a null value returned when the property is referenced is good enough.

If($User -NE $Null -AND $User.PSObject.Properties.Match('EmployeeId').Count) { ... }

This works. The -AND operator in Powershell works like a "short circuit" && operator in most programming languages, meaning that if the first expression does not satisfy the requirements for entering the code block, then the second expression is not evaluated. This is perfect, because if I accidentally feed a null user object to the code above, I would have gotten the same error about the $User object not containing a PSObject property.

Alright, back to scripting!