Goatee PFE

Touch-Free PowerShell DCPROMO in Windows Server 2012

2013-04-18T12:00:00Z

DCPROMO Keeping You Up At Night?

Do you schedule DCPROMO activities for the weekend? After hours? Middle of the night? I remember those days. Often it was hard to get in the right frame of mind to think through all of the exact procedural steps during those late night change controls. It was always good to have a thorough implementation plan.

Today’s post will show you how to easily promote and demote a Windows Server 2012 domain controller remotely with a script. You don’t even need to logon to the target server.

PowerShell DCPROMO in Windows Server 2012

In Windows Server 2012 DCPROMO is gone. The replacement is the ADDSDeployment module, and it is packed full of PowerShell goodness. Another key fact is that remoting is enabled by default in Windows Server 2012. See the potential here? Now that we’re in PowerShell land we can use remoting to promote a DC without logging on. The new Server Manager GUI uses this same technique.

PS C:\> Get-Command -Module ADDSDeployment | ft Name

Name
----
Add-ADDSReadOnlyDomainControllerAccount
Install-ADDSDomain
Install-ADDSDomainController
Install-ADDSForest
Test-ADDSDomainControllerInstallation
Test-ADDSDomainControllerUninstallation
Test-ADDSDomainInstallation
Test-ADDSForestInstallation
Test-ADDSReadOnlyDomainControllerAccountCreation
Uninstall-ADDSDomainController

Change control. Can’t live with it. Can’t live without it.

Scripting a change control is handy for several reasons:

If your shop has a separate implementation team, then you know they should execute it precisely.
You can test it in a lab, and then do it the same way in production.
You know exactly what changed.
You don’t have to worry about missing a step at 3AM.

Generally change controls have three plans:

Implementation
Validation
Back-Out

You have all three of these scripts for DCPROMO in today’s post. Read through the scripts and the comments to see how easy it can be.

Script Overview

The DCPROMO implementation script hinges on three key cmdlets:

Install-WindowsFeature
Invoke-Command
Install-ADDSDomainController

First, we install the role for Active Directory Domain Services using the ComputerName parameter. Next we use Invoke-Command to remotely execute the DCPROMO with Install-ADDSDomainController. Notice the comments in the code for Invoke-Command. It is really important to understand the $using variable prefix. This little item tripped me up for several hours until a peer reminded me about it. See about_Remote_Variables for the full explanation.

The validation script is short and sweet. It checks for the new AD domain controller object, key services, and the SYSVOL share. Obviously there are many other checks you could add. See the link at the bottom of this post for a great DC validation checklist.

Finally, the back-out script is much like the implementation script, except it calls the uninstall cmdlets in reverse order.

Implementation

# Prompt for credentials to reuse throughout the script            
$cred = Get-Credential Cohovineyard\Administrator

# Echo the date for reference in the console output            
Get-Date

# Query the current list of domain controllers before the new one            
Get-ADDomainController -Filter * |            
    Format-Table Name, Site, IPv4Address -AutoSize

# Import the module containing Get-WindowsFeature            
Import-Module ServerManager

# List the currently installed features on the remote server            
Get-WindowsFeature -ComputerName cvmember1.cohovineyard.com |             
    Where-Object Installed | Format-Table Name

# Install the role for AD-Domain-Services            
Install-WindowsFeature –Name AD-Domain-Services ` 
    –ComputerName cvmember1.cohovineyard.com ` 
    -IncludeManagementTools

# List the currently installed features on the remote server            
# Notice AD-Domain-Services is now in the list            
Get-WindowsFeature -ComputerName cvmember1.cohovineyard.com |             
    Where-Object Installed | Format-Table Name

# Promote a new domain controller in the existing domain            
# Adjust the parameters to meet your own needs            
# Notice we're going to handle the reboot ourselves            
##### BIG THING TO NOTICE #####            
# Notice that the -Credential parameter variable is prefaced with "$using:".            
# This is a PS v3 feature, and it is required when passing variables            
# into a remote session. Invoke-Command is based on PowerShell remoting.            
# Any other parameters that you turn into variables will need "$using:".            
Invoke-Command –ComputerName cvmember1.cohovineyard.com –ScriptBlock {            
            
    Import-Module ADDSDeployment;            
            
    Install-ADDSDomainController ` 
        -NoGlobalCatalog:$false ` 
        -CreateDnsDelegation:$false ` 
        -CriticalReplicationOnly:$false ` 
        -DatabasePath "C:\Windows\NTDS" ` 
        -DomainName "CohoVineyard.com" ` 
        -InstallDns:$true ` 
        -LogPath "C:\Windows\NTDS" ` 
        -NoRebootOnCompletion:$true ` 
        -ReplicationSourceDC "CVDC1.CohoVineyard.com" ` 
        -SiteName "Ohio" ` 
        -SysvolPath "C:\Windows\SYSVOL" ` 
        -Force:$true ` 
        -Credential $using:cred ` 
        -Confirm:$false ` 
        -SafeModeAdministratorPassword ` 
            (ConvertTo-SecureString 'P@ssw0rd' -AsPlainText -Force)            
}

# We are going to manage the restart ourselves.            
Restart-Computer cvmember1.cohovineyard.com ` 
    -Wait -For PowerShell -Force -Confirm:$false

# Once fully restarted and promoted, query for a fresh list of DCs.            
# Notice our new DC in the list.            
Get-ADDomainController -Filter * |            
    Format-Table Name, Site, IPv4Address -AutoSize

# Echo the date and time for job completion.            
Get-Date

Validation

Import-Module ActiveDirectory

# Query the current list of domain controllers            
Get-ADDomainController -Filter * |            
    Format-Table Name, Site, IPv4Address -AutoSize

# Check random services common to DCs            
Get-Service adws,kdc,netlogon,dns -ComputerName cvdc1

# Check for presence of SYSVOL            
Test-Path \\cvdc1\SYSVOL

Back-Out

# Prompt for credentials to reuse throughout the script            
$cred = Get-Credential Cohovineyard\Administrator

# Echo the date for reference in the console output            
Get-Date

# Query the current list of domain controllers before the removal            
Get-ADDomainController -Filter * |            
    Format-Table Name, Site, IPv4Address -AutoSize

# Reset the error variable            
$error.Clear()

# Remove the domain controller in the existing domain            
##### BIG THING TO NOTICE #####            
# Notice that the -Credential parameter variable is prefaced with "$using:".            
# This is a PS v3 feature, and it is required when passing variables            
# into a remote session. Invoke-Command is based on PowerShell remoting.            
# Any other parameters that you turn into variables will need "$using:".            
Invoke-Command –ComputerName cvmember1.cohovineyard.com –ScriptBlock {            
            
    Uninstall-ADDSDomainController -Confirm:$false ` 
       -LocalAdministratorPassword ` 
            (ConvertTo-SecureString 'P@ssw0rd' -AsPlainText -Force) ` 
       -DemoteOperationMasterRole:$true ` 
       -Credential $using:cred ` 
       -Force:$true            
}

# Exit if the uninstall was unsuccessful            
If ($error) {break}

# Give the server time to go down            
Start-Sleep -Seconds 5

# The DC removal also removes the host A record in DNS.            
# This effectively disables any other remoting until the server reboots.            
# Therefore we tell the Uninstall to do the reboot by omitting the            
# switch -NoRebootOnCompletion, and then we loop until we can confirm            
# the server is reachable again and services are started.            
Do    { Start-Sleep -Seconds 1 }            
Until (Get-CIMInstance Win32_Bios ` 
        -ComputerName cvmember1.cohovineyard.com ` 
        -ErrorAction SilentlyContinue)

# Uninstall the AD DS & DNS roles            
Import-Module ServerManager            
Uninstall-WindowsFeature ` 
    –Name AD-Domain-Services, DNS, RSAT-AD-Tools, RSAT-AD-PowerShell ` 
    –ComputerName cvmember1.cohovineyard.com ` 
    -IncludeManagementTools ` 
    -Confirm:$false

# Restart the server and wait for services to come back up            
Restart-Computer cvmember1.cohovineyard.com ` 
    -Wait -For PowerShell -Force -Confirm:$false

# View the roles to verify that AD-Domain-Services is really gone            
Get-WindowsFeature -ComputerName cvmember1.cohovineyard.com |             
    Where-Object Installed | Format-Table Name

# Query for a fresh list of DCs. Confirm it is gone from the list.            
Get-ADDomainController -Filter * |            
    Format-Table Name, Site, IPv4Address -AutoSize

# Echo the date and time for job completion.            
Get-Date

Script Notes

Like other demo scripts I’ve posted there is plenty of room for improvement. Consider these key opportunities regarding the scripts above:

The functionality in these scripts requires Windows 8 with RSAT or Windows Server 2012.
Be sure to adjust the values for the parameters on the cmdlets that do all of the heavy lifting.
Use Read-Host to prompt for the password instead of embedding it in plain text.
Add a Start-Transcript and Stop-Transcript for logging your activity.
End the script with a Send-MailMessage that attaches the transcript in an email to you.
You can swap out all of the hard-coded computer names with variables to make it more reusable.
You could promote the DC from your smartphone with one hand tied behind your back.
You could schedule the script to run at 3AM while you are nestled in bed.

Download the full code from the TechNet Script Gallery.

See this TechNet article for the complete textbook explanation of promoting a new DC in Windows Server 2012:
Install a Replica Windows Server 2012 Domain Controller in an Existing Domain (Level 200)

My buddies over at the AskPFEPlat blog have a great checklist for introducing and removing DCs. Use this list to build your own robust validation script:
First, Do No Harm

Another buddy on AskPFEPlat has written a great article for your first 2012 DC:
Introducing the first Windows Server 2012 Domain Controller (Part 1 of 2)

Active Directory OU Permissions Report: Free PowerShell Script Download

2013-03-25T15:55:00Z

Who owns your OUs?

Have you ever lost your keys? It is a scary feeling. Someone out there could have keys to your house and your car. Your personal safety could be at risk. The same is true in Active Directory. Do you know who has the keys to all of your accounts?

The Problem

In Active Directory we need to know who has the keys to our organizational units (OUs), the place where our users and computers live. Over the years OUs have grown to meet needs. Different teams may have been delegated access for managing users, groups, and computers. Then you come along as the new administrator. You probably have no idea where permissions have been granted to your OUs. And the scary thing is… neither does anyone else. I know, because I’ve been there. I hear the same thing from our customers.

Out-of-the-box we do not have a specific tool to report all of the OU permissions. You have to click each OU and view the security tab one-by-one, and we all know that is entirely impractical. Today’s post contains a script download to generate a report of this vital information.

OU Permissions

OU permissions are multi-faceted. In other words… it’s complicated. They have a number of properties:

Principal
Allow/Deny
Scope
Applies To
Permissions

You’ll see the following dialog when you add a permission. This is enough to explain the complexity of the group access notation:

Now look how many Applies to: options there are. Notice that this box scrolls a long way.

What we need is a report that lists the contents of the Advanced permissions GUI like this for every OU:

The matrix of potential permission configurations is mind-blogging.

The Solution: PowerShell

I had wondered if a report like this could be as simple as:

Import-Module ActiveDirectory
cd AD:
dir –recurse –directory | Get-ACL

Of course what works in our imaginations is rarely as simple in real life. No, that code would not do it. However, the concept is the same:

Get a list of all OUs
Loop through the OUs to retrieve their permissions
Export all data to a CSV file

Our good friend Get-ACL reports on more than file system permissions. We can use this same cmdlet to query OU permissions as well. Notice that we preface the OU distinguished name with AD:\. Any time you query permissions with Get-ACL you need to expand the Access property to see the list of permission entries (ACEs):

Get-Acl -Path "AD:\OU=Domain Controllers,DC=wingtiptoys,DC=local" |
  Select-Object -ExpandProperty Access

Here is an example of an ActiveDirectoryAccessRule object that is returned for an OU:

We get an entry like this for every permission assigned to the OU. My first instinct was to simply dump a list of these to CSV and be done with it. But then I noticed the ObjectType and InheritedObjectType properties. Hmmmm. These are ugly GUIDs… not what we need for the report. We need to translate these to the names of the objects that receive the permissions. These names are what we see in that long drop-down list in the screenshot above.

To make a long story short I stayed up until 3AM researching this and traced it all down in the Active Directory Technical Specifications (MS-ADTS) here:

You are welcome to read these pages for yourself to understand the relationships. Essentially these GUID values are stored on attributes of selected objects in the schema and configuration partitions of the AD database. You can query these to build a list of names that will make the report readable. So that’s what I did and put them into a hash table for quick look-ups when we generate the report.

The Big Finish

When we script it all out we get a report that looks something like this:

Obviously there are too many columns to read in the screenshot, but it is quite thorough. Now you can use filters and pivot tables in Excel to analyze the data and produce reports showing exactly which OUs have delegated permissions, what kind of permissions, and who has them. Likewise you can pivot the report by group to see a list of all OUs that a group can control. You may want to filter the output by the IsInherited property. By filtering for FALSE you will find everywhere that permissions are explicitly delegated in the OU tree.

Conclusion

I would advise all Active Directory shops to run and review this report on a quarterly basis to make sure there are no surprise administrators lurking in your domain. The report can be quite large for any size organization. Perhaps this would be a good report to feed to the Information Security team, if you have one. Now you know who holds the keys.

Download the full script from the TechNet Script Gallery.

How to do PowerShell on your phone

2013-02-05T16:05:00Z

Even Spiderman would envy this web action. Today we're going to walk through setting up a portable PowerShell v3 Web Access demo. Using this demo guide you can explore PowerShell from any web-capable device: your phone, your tablet, or your Raspberry Pi. The links in this post will guide you to all of the key documentation to build your own PowerShell Web Access lab.

Thanks to my buddy Bruce Adamczak for the picture above. Bruce snapped it while I was doing this demo for a customer in the field.

A couple weeks ago I was flying home from helping a customer get their Active directory healthy, and it dawned on me that I had everything I needed for a wow-factor PowerShell demo right there in my backpack. When I landed in Atlanta I put this demo together between flights. I was grinning ear-to-ear with my laptop, Surface, and Windows Phone sprawled out on one of those tiny airport waiting area seats. I know people thought I looked goofy… dude with a goatee grinning at his laptop and tablet and phone all at once.

One of my favorite Iron Man quotes is from the first movie when Obadiah Stane says, "Tony Stark was able to build this in a cave… with a box of scraps!" In other words, this demo will only take a few pieces to get rolling. And I’m not Tony Stark.

The Plan

The demo consists of a domain controller VM and an IIS VM running on my laptop, both on an internal network. The IIS VM has another virtual network connection configured for the external network with a static IP at the upper end of the same IP range issued from DHCP on the WiFi access point. My phone and tablet are getting DHCP from the same WiFi access point. Technically we could put the DC on the same external network, but using a separate internal network would be more like reality where the web server has a reverse proxy to access internal resources. Here is a crude illustration: (Hey, I’m an engineer, not an artist.)

The Parts

Here is all you need to get this going:

A wireless access point - I used my Verizon MiFi.
A laptop running Windows 8 Client HyperV.
A wifi tablet with a browser - I used my new Microsoft Surface RT.
A wifi smartphone with a browser - I used my Verizon HTC 8X Windows Phone 8.

Wireless

Any WiFi access point or router should do. Configure DHCP so that you have at least one extra address above the range. This extra address will be statically assigned to your IIS server external virtual NIC. I used the address 192.168.1.200.

Client HyperV

You’ll need a 64 bit install of Windows 8. Most newer laptops have SLAT (second layer address translation) built in to support Client HyperV. Install HyperV from Windows Features. Use this post for setup instructions.

Technically you would only need one VM for this demo: a Windows Server 2012 install running Directory Services and IIS. Obviously that would never be recommended in a production environment. I have four VMs for more demo flexibility:

Windows Server 2012 Domain Controller
Windows Server 2012 Member Server
Windows Server 2012 IIS Server
Windows 8 client

You can download evaluation installs here for your own free testing:

All of the VMs are joined to the test domain on the DC.

Networking

This is the tricky part. I'm not a HyperV expert, but I know enough to configure internal and external networks using the virtual switch (after I read the help). VMs on the internal network use the static addresses pictured in my crude illustration above. Then I can use Remote Desktop Connection Manager to RDP into each virtual server from the host laptop where I have a static IP configured on the internal bridge NIC. The RDP part is optional but convenient. Most folks will use the HyperV virtual machine connection to interact with the VMs.

On the web server VM I configured two NICs: one internal and one external. Inside the VM the internal NIC has the static 10.x.x.x address and the external NIC has the static 192.168.1.200 address.

Web Server

Once you have built your IIS VM you can use this article from the PowerShell team to step through the PowerShell Web Access setup. I was surprised that this only took five minutes in my lab. They did a good job building the setup cmdlets to automate all of the IIS configuration. Call the site "pswa". Here is another link for more setup options. If you want the full textbook documentation it is on TechNet here.

Web Clients

Now create a favorite or shortcut from Internet Explorer on the Windows 8 client VM, on the tablet browser, and on the phone browser. The URL should look something like this: https://192.168.1.200/pswa . Any browser that supports HTTPS, JavaScript, and cookies should work.

PS – I tried this on my XBOX with the new IE app. However, it did not appear to work. From what I understand the XBOX browser does not support JavaScript. I could be wrong. Let me know if you get this to work.

Bringing It All Together

Once you’ve walked through these links and ironed out the kinks you should have a working PowerShell Web Access lab. When you hit the URL you’ll get a page that looks like this. Note that I have filled in the credentials and target computer name.

By the way, you will likely get a security prompt in the browser that the web site’s certificate is invalid. You can safely ignore that, because we’re just using a test certificate in the lab. For Windows clients you may need to launch the browser as Administrator to bypass that warning.

After clicking the Sign In button you’ll get the PowerShell console. As they say in the movies, “I’m in!”

See this article for all of the tips on using the PowerShell Web Access console. You’ve got to try this from your phone. For example, most phone touch keyboards do not have a TAB key for doing TAB completion in the PowerShell console. That’s why we put the little TAB icon on the toolbar at the bottom. We also added up/down arrows for cycling through the command history.

A PFE peer of mine, Rick Sheikh, wrote a very thorough post recently on PowerShell Web Access. I would encourage you to read it for all of the possible configuration and security options you can tweak.

Bring The Wow

Now what? We’re in. Any way to add some “wow” to this demo? You bet.

Go watch this TechEd session with Travis and Hemant. Fast forward to the 52 minute mark where they discuss disconnected sessions and then transition to PowerShell Web Access. I posted a copy of these demo scripts when I spoke at TechMentor last autumn. (Thanks, Travis and Hemant!) Download the scripts, watch the video demo, and see if you can recreate the part at the end where they “pull a rabbit out of the hat” in the web session. That’s the wow, especially when you do it from your phone. I saved the commands into a demo.ps1 script to run from the phone instead of typing it all during a live demo.

Presentation Setup

When I do this demo for an audience here are the steps I take to utilize the lab:

Boot up the Verizon MiFi and connect the devices. I have already added the wireless network to my phone and Surface so that they connect right away.
Boot up the VMs on my laptop.
Create a shortcut on the phone and tablet pointing to the PowerShell Web Access page hosted on my laptop VM. Test the page from each device to make sure it is working.
Connect my laptop to the projector. Plug in the Surface VGA dongle so that it is ready.
Enable Presenter mode on the laptop and the Surface. (Windows + X, Mobility Center, Presentation Settings)
Do the PowerShell Web Access talk from the laptop. Use the scripts linked above for the demos. Start the disconnected job with the counting demo.
Switch over to the Windows 8 client VM and demo PowerShell Web Access from a normal desktop browser but don’t pull the results from the disconnected session yet. Discuss convenience at work or at home.
Disconnect the VGA cable from the laptop and plug it into the Surface VGA dongle.
Launch the PowerShell Web Access shortcut from the tablet. Log in. Demo a couple commands from the web console but don’t pull the results from the disconnected session yet. Discuss how cool this would be from the recliner at home.
Switch over to the Camera app on the Surface. Now the camera is live on the big screen. Tell the people in the front row to wave.
Position the phone in front of the tablet camera so the audience can see it. Launch the shortcut for PowerShell Web Access on the phone. Turn it to landscape mode. Log in. Discuss how handy this is if you have to fix something at work while at a soccer game with the kids.
Demo PowerShell from the web console on the phone. Do a “dir” to show the demo.ps1 file you pre-staged earlier in the Administrator profile folder on the server. Then type “Get-Content .\demo.ps1” to show what the script will do. You can use TAB complete with Get-Content for added effect.
Now run the demo.ps1 file with the two lines to reconnect the session and display the running output from the disconnected session. Wow!

Imagine The Possibilities

As you might guess the setup will require some time on your part. It is not really that difficult, but there are a lot of steps. The fun part is all the learning along the way. And when you’re done it is quite impressive. Sometimes I run the lab on my home network so that I can use my Windows Phone or Surface to play with PowerShell from anywhere in the house. Yip. I’m a geek. And I bet you are, too, if you’re still reading at this point.

Now that you have a super-cool PowerShell Web Access lab what can you do with it? With over 2,400 cmdlets to explore and PowerShell under the covers of all the Windows server products the sky is the limit. Imagine the possibilities for remote administration now across all products and technologies with PowerShell from your phone or tablet.

Typing on the phone keyboard may be tedious, but when you’re offline at a family event it is much easier than driving into the office to take care of business. And that is why we created PowerShell Web Access. Time for some PowerShell web slinging. Enjoy!

Called Out: From 2012 to 2013

2013-01-30T14:00:00Z

Called Out

Departing from the usual scripting today's post is a reflection on 2012 and a look ahead at goals for 2013. The overall theme today is the Heroes To Mentors vision we have embraced within Microsoft PFE.

Brian Jackett is a coworker and friend of mine (pictured far left above) who specializes in SharePoint and PowerShell. He has been very active in the SharePoint community coordinating and speaking at events. He's a great PFE, and I'm sure you would enjoy having him come to your company to help with your SharePoint or teach a workshop. Check out his blog here.

Brian "called me out" in his blog post this month. Each year he blogs about his goals for the year and encourages colleagues to do the same. This time Josh and I drew the short straw. (grin) Thanks, Brian. Really, this is a good thing to do, and I encourage everyone to do the same. I've done this in some form or fashion over the last few years, and it has always been a rewarding experience.

Last Year In Review

Last autumn I celebrated two years of blogging on TechNet, and I have continued to meet my goal of one solid post monthly. Many of you have either commented or contacted me through the blog, and I enjoy that dialog. Keep it coming. Here are my top five posts of all time based on traffic:

In 2012 I also had the privilege of meeting many of you in person either on site as a Premier customer, at a conference, or at a user group event. It has been fun sharing Active Directory PowerShell and new PowerShell v3 features with you in person:

March - PowerShell Saturday, Columbus, OH
July - TechReady, Seattle, WA
August - TechMentor, Seattle, WA
September - PowerShell Saturday, Charlotte, NC
November - DogFoodCon, Columbus, OH

Thanks to your visits my blog has consistently ranked in the top 10% of TechNet blog traffic for the last year. Thank you for your support and feedback. This blog is all about helping folks with practical needs. Let me know if there are topics you would like me to cover here.

I should also thank all of you who have Tweeted my blog posts. It is encouraging, and I appreciate your help spreading the good news of PowerShell for Active Directory.

2013 Professional Goals

This year I was promoted to senior PFE, and I want to make the most of it. I want to develop others around me and share more development opportunities with my peers as my mentors have done for me. Bruce Adamczak was the first to follow my lead and started a very successful TechNet blog. Next I have invited Tom Moser to co-present with me at an upcoming internal training event.
PFE Industry Leadership is one of our goals as an organization within Microsoft, telling the value story of PFE and helping build the brand. I enjoy talking about the cool stuff we get to do as PFEs. This builds "street cred" in the community for us individually and for Microsoft as a company. I will explore this more in the coming year and develop a training guide for PFEs who want to speak at conferences.
Ed Wilson took me under his wing as a mentee last year, and we are both enjoying our monthly conversations. Ed and Theresa have both become good friends, and I look forward to more mentoring this year. Thank you, Ed, for the opportunities you have given me.
I really enjoy blogging and scripting. This year I plan to publish some updates for the SIDHistory PowerShell Module, and I would like to write a new module for cleaning up groups in Active Directory. Send me your ideas on what would help with group cleanup.

2013 Personal Goals

Like Brian I am a man of faith, and I want to grow closer to God. I have already begun getting up 30 minutes earlier each day to pray and read the Bible. Any parent of teenagers would agree with me that more prayer is a good thing.
In February I will begin getting up another 30 minutes earlier to exercise in some awkward geek fashion. I plan to alternate days between cardio and strength training. I tried jogging two years ago and quickly developed a stress fracture in my right knee (twice). I plan on easing into it this time.
Brian is getting married this year, and I have been married for 21 years. I always strive to be a better husband and father, and this year is no different. We have some special family events coming up this year, and I am looking forward to those. PS - Brian, my wife and I fondly refer to those pictures of our pre-marriage years as… "the skinny pictures".

This is an exciting time in IT and especially at Microsoft. I am really enjoying our new releases: Windows Phone 8, Surface, Windows 8, Windows Server 2012 and PowerShell v3. I look forward to what our customer can accomplish with these new tools both personally and professionally. Let me know how I can help. Consider yourself "called out".

Ashley
GoateePFE

Free Download: CMD to PowerShell Guide for AD

2013-01-02T14:00:00Z

New Years Resolution

Hi folks. It's your friendly, neighborhood PFE again. In order to avoid the long lines to buy a treadmill the first week of January I thought I would save you some time and give you an easier New Years Resolution… Learn PowerShell.

It's time to part with "blankie".

For years many of us have relied on trusty command line utilities like PING, IPCONFIG, and REPADMIN. Some of us are still hanging on to those instead of embracing the brave new world of PowerShell.

In an effort to assist with the transition and to introduce some of the cool new cmdlets in PowerShell v3 I have created a free reference guide showing how the old meets the new. For example, instead of PING try the PowerShell cmdlet Test-Connection, instead of NSLOOKUP use Resolve-DNSName, instead of GPUPDATE use Invoke-GPUpdate.

The guide attached at the bottom of this blog post contains four packed pages of PowerShell pleasure for your perusing.

Why?

Why would someone want to use PowerShell instead of command line utilities? There are several reasons:

Command line utilities often give us the data we want, but it is flat text that requires parsing to do anything else with it. Have you ever scripted a command line PING and tried to find the result? Yeah, I have, and it's a pain. Now with PowerShell you can simply reference the ping result properties coming back to easily get the actual data involved.
Is your favorite command line utility always available? When you would RDP to a server back in the day you had no idea if the adminpak.msi or the Windows Resource Kit was installed. Now you know that PowerShell is always there on Windows Server 2008 R2 and above.
PowerShell cmdlets mostly use the same syntax. You no longer have to figure out what the right switch is for the remote computer name. Now it is always "-ComputerName".
PowerShell is not just the future, it's now. Version 1 was released five years ago. Now all of the Microsoft server products use PowerShell. Windows 8 and Server 2012 now have thousands of cmdlets at your finger tips.

Free Download

While studying the new 2012 cmdlets in preparation for conference talks last summer I created a quick cheat sheet for PowerShell equivalence to REPADMIN and DNSCMD. The other day I sat down and expanded this to include a raft of familiar utilities:

REPADMIN
DCPROMO
CSVDE
NETDOM
NLTEST
GPUPDATE
GPRESULT

DSGET
DSQUERY
DSADD
DSMOD
DSRM
DSMOVE
DSACLS

DNSCMD
NSLOOKUP
PING
IPCONFIG
NETSTAT

This guide will get you off and running to convert any old batch files you still have lying around or hiding in scheduled tasks.

Four pages. Really?

Yes. I know that sounds like a lot to learn, but the good news is I can't remember them all either. I work for Microsoft, and I still use Show-Command, Get-Command, and Get-Help on a daily basis. That's why we put those cmdlets in the box. With over 2,400 cmdlets now there's a good chance we've got you covered for anything you need. If not, let us know on the Connect site.

There are so many command line utilities out there that I had to limit my focus to those related to Active Directory. Hopefully this post will inspire others in the community to compile similar guides for their technologies.

Disclaimer

I created this guide based on my personal knowledge of the tools and the help text that they print. In other words this is not a top secret guide published by Microsoft product groups, and I have not tested every single entry. Some of these will require you to use Get-Help to explore the capabilities. I built this by hand in Excel, so you may be able to find some gaps in the list. If you find any omissions or corrections please send them my way, and I'll update the document.

Enjoy. Happy New Year!

photo credit: eccampbell via photopin cc

TIP: 2 Ways userAccountControl Is Easier In AD PowerShell

2012-12-13T14:00:00Z

Background

Anyone who wants to write scripts for Active Directory will eventually run into the famous userAccountControl attribute. Usually this comes up when you are searching for disabled accounts. Actually this attribute is a bit flag for 22 different account settings! You can find them clearly documented in KB305144. In the GUI you find these settings represented by checkboxes in Active Directory Users and Computers (ADUC) (pictured right).

I’ve done my share of VBScripts over the last 10 years, and this always took more lines of code than I wanted to write. In this example on the Hey Scripting Guy blog you can see it would take 14 lines of code to report on disabled accounts. To make matters worse you had to understand LDAP bitwise filter syntax. In an earlier post I demonstrated this syntax for querying AD based on a bit value.

The good news is that in Windows Server 2008 R2 and above we have two cmdlets that make this easy.

One Line Of PowerShell

With the Active Directory module for PowerShell and the Search-ADAccount cmdlet those 14 lines of VBScript turn into a single line:

PS C:\> Search-ADAccount -AccountDisabled

To limit the results to users or computers you can try one of these handy switches:

PS C:\> Search-ADAccount –AccountDisabled –UsersOnly

PS C:\> Search-ADAccount –AccountDisabled –ComputersOnly

The Search-ADAccount cmdlet has several switches that target the userAccountControl bit flags:

AccountDisabled
AccountExpired
AccountExpiring
LockedOut
PasswordExpired
PasswordNeverExpires

Now we don’t have to fuss with all of the fancy LDAP syntax.

But wait… there’s more!

The Set-ADAccountControl cmdlet gives us 12 switches to toggle these checkboxes via script:

AccountNotDelegated
AllowReversiblePasswordEncryption
CannotChangePassword
DoesNotRequirePreAuth
Enabled
HomedirRequired
MNSLogonAccount
PasswordNeverExpires
PasswordNotRequired
TrustedForDelegation
TrustedToAuthForDelegation
UseDESKeyOnly

Now you can turn the flags on and off like this:

PS C:\> Set-ADAccountControl JoeUser –PasswordNeverExpires $true

PS C:\> Set-ADAccountControl JoeUser –PasswordNeverExpires $false

Wow! Now that was easy.

PS…

Closing reminders:

You’ll need the RSAT for Windows 7 or Windows 8 to get the cmdlets on your workstation.
Don’t forget to type Import-Module ActiveDirectory before trying these one-liners.
You can even run these against legacy 2003 or 2008 domain controllers using the guidance here.

Enjoy!

AD PowerShell Password Reset Shortcut for Helpdesk

2012-11-26T14:00:00Z

Introduction

Back in May I released a post on the Hey Scripting Guy blog showing how to create a shortcut to unlock a user account with a PowerShell desktop shortcut. That post was very popular, and the comments evolved into another shortcut to reset passwords. Due to the popularity and utility of the idea I decided it deserved its own blog post. I’ve also learned a little more about the Set-ADAccountPassword cmdlet to simplify my previous code.

Monday Morning on “The Desk”

You know the drill. It’s Monday morning. Last Friday 47 users decided it was a good idea to change their password before the weekend. It’s Monday. They forgot, just like I would. Personally I never change my password on a Friday for this reason. I need a couple days to use it before the weekend.

What could make this worse? Holiday weekends… like US Thanksgiving. (grin) Now it’s been at least five days since I reset that password. There’s no chance I’ll remember it unless it’s written down on that sticky note under the mouse pad.

Now all 47 of those users must call the helpdesk first thing Monday before they can begin another week of productivity for the company. The self-service password project has not gotten enough budget or resources for implementation, and until it does every Monday morning is going to look very familiar. That’s where we come in with PowerShell.

The Options

How many different ways can we reset a password? Let’s make a quick list:

Active Directory Users and Computers (ADUC) – Despite the several clicks involved this is the first choice for many folks. It’s been working for 12 years now. Why change now?
Active Directory Administrative Center (ADAC) – This is the new AD-GUI-with-PowerShell-under-the-covers version of ADUC, and it puts password resets on the front page for easy access. Give this one a try. It’s free with your Windows Server 2008 R2 (or 2012) RSAT. This is slightly faster.
DSMOD – Yeah. It’s an option, but you need to type the distinguished name for the user. Cool, but just not practical.
That in-house identity app written seven years ago by a special project team in InfoSec. Um. Yeah. Way too many clicks.
PowerShell. Wait… can you click in PowerShell? Kind of. It’s going to be a single double-click. Much faster.
Etc.

Bring The ‘Shell To The ‘Desk

Attached at the bottom of this post you’ll find a simple text file with these lines (note that these one-liners have been wrapped for display purposes):

: 100 characters
: Reset Password
@echo off&&powershell -NoE -C "&{ipmo ActiveDirectory;
Set-ADAccountPassword (Read-Host 'User') -R}"

: 123 characters
: Reset Password
: User must change password at next logon
@echo off&&powershell -NoE -C "&{ipmo ActiveDirectory;
Set-ADAccountPassword ($u=Read-Host 'User') -R;Set-ADUser $u -Ch 1}"

: 154 characters
: Reset Password
: User must change password at next logon
: Alternate credentials @echo off&&powershell -NoE -C "&{ipmo ActiveDirectory;
Set-ADAccountPassword ($u=Read-Host 'User') -R -Cr ($c=Get-Credential);
Set-ADUser $u -Ch 1 -Cr $c}"

: 191 characters
: Reset Password
: User must change password at next logon
: Alternate credentials
: Target a specific DC
@echo off&&powershell -NoE -C "&{ipmo ActiveDirectory;
Set-ADAccountPassword -Cr ($c=Get-Credential) -S ($s=Read-Host 'DC')
 -I ($u=Read-Host 'User') -R;Set-ADUser $u -Ch 1 -Cr $c -Server $s}"

Depending on how you would like to perform the password reset there are four options presented here for your shortcut. Simply copy the line you want to use and paste it into a batch file on the desktop for the helpdesk. Here are the flavors:

Password reset
User must change password at next logon (always a good idea)
Reset the password using alternate credentials
Target a different domain controller to initiate the change

Just copy the line you want into a text file on the desktop and put ‘.BAT’ at the end of the file name. Enjoy!

The Code

At first glance these lines may be a bit challenging to understand. That’s because I’ve maximized the use of aliases and abbreviations to tighten these lines down to merely a few characters. I usually avoid these for readability, but in this case I was aiming for brevity. Plus it’s just fun.

Let’s break down the longest line:

@echo off

This is batch language to hide the commands when you run them.

This is how we cheat in batch language and put everything on one line.

powershell -NoE –C

Launch PowerShell, leave the window open when complete (in case there are any errors to view), and run this command…

Now we’re in PowerShell, and the ‘&’ is the invoke operator. This tells PowerShell to run everything inside the code block { }.

ipmo ActiveDirectory;

Import-Module ActiveDirectory. Then ‘;’ is the new line character so we can cheat in PowerShell and keep it all on one line.

Set-ADAccountPassword -Cr ($c=Get-Credential) -S ($s=Read-Host 'DC') -I ($u=Read-Host 'User') -R;

This is where the magic happens. There is no alias to shorten the cmdlet, but we’ve abbreviated all of the parameters: Credential, Server, Identity, and Reset. By capturing each of these values into a variable we can reuse them in the next cmdlet without having to prompt for the values again.

Set-ADUser $u -Ch 1 -Cr $c -Server $s}"

ChangePasswordAtLogon become ‘Ch’. ‘Cr’ again is Credential. Because this cmdlet has so many parameters beginning with ‘S’ we have to use the full parameter name for ‘Server’.

What other language could do this in less than 200 characters? Now that’s PowerShell!

One Small Prerequisite

In order for the helpdesk to use this code they will need to install the Windows 7 or Windows 8 Remote Server Administration Tools (RSAT) and turn on the feature Active Directory Module for Windows PowerShell. Most likely the RSAT are already installed for other administrative tasks, so they can check the GUI box pictured here:

‘Tis The Season

Password resets will never go out of season. Armed with these new batch lines perhaps your Monday mornings will go faster and the elves in the toy shop can get back to what they do best… making new Microsoft Surface tablets to put under the Christmas tree.

DogfoodCon 2012 - Columbus, Ohio

2012-11-09T14:00:00Z

Today I have the privilege of speaking at DogfoodCon 2012 in Columbus, Ohio. My topic is “Active Directory PowerShell Step-By-Step”. This post includes a download of the slide deck and demo scripts for the session.

Here are the resource links that I shared today:

AD Group History Mystery: PowerShell v3 REPADMIN

2012-10-17T13:00:00Z

I remember back in high school the janitor had this massive ring of keys on his belt. The keys would jingle with each step as he pushed the broom down the hall. It was like his own percussion section accompanying the tune he whistled. So what does this have to do with PowerShell?

The Scenario

After speaking about SID history and token size at PowerShell Saturday last month an attendee approached me with a common concern. I was so excited to code the answer that I did it in the airport on the way home.

Joe User has been with the company for 23 years and has accumulated more group memberships than the entire desktop support team. Joe has rotated through five different departments during his career and managed to survive all of the layoffs. As a result he has access to every share in the company. Even worse his access token is so big that it won’t fit through the door.

We would love to clean up his group memberships, but we have no way of knowing when he was added to all these groups. If we could see the dates he joined those groups it would give us a clue about removing just the older group memberships. Without this information his token will continue to bloat… just like that overloaded key ring swinging on the janitor's hip.

Where can we find group membership details?

When you look into the member attribute of an AD group you’ll find a list of all members in distinguished name format. But that’s it. There is no smoking gun or finger prints that tell you how they got there. However, there is a little-known piece of data called replication metadata that can tell us exactly what we need. This data is quite special for groups, because it shows us the date individual members were added and removed. Awesome! But if you try to view it in the GUI it looks like ugly hex.

REPADMIN is so last decade

That’s where REPADMIN helps with the handy showObjMeta parameter. While this command will show us the data, it wraps and scrolls so much in the console that it is difficult to read. Also it is extremely painful to parse with any kind of script.

Try it for yourself:

repadmin.exe /showObjMeta DCNAME “CN=GroupName,OU=SomeOU,DC=contoso,DC=com”

This is a cool command that I’ve used for forensic investigations in the past to see when an attribute was last modified and which DC originated the change. Then you may be able to trace it down in the logs on that DC to find the account that made the change. You can read more about this here and here.

Can I do it with PowerShell? Please say yes.

Way back in PowerShell v1 MVP Brandon Shell wrote a script called Get-ADObjectReplicationMetadata to do this. The AD cmdlets in PowerShell v2 had little parity with REPADMIN. Now in PowerShell v3 the AD cmdlets have made good progress. We still have a ways to go, but you can see in the chart below that PowerShell is catching up with REPADMIN. This is an unofficial comparison chart that I created based on my own observations. Any corrections or additions are welcome.

Notice now we have one of my new favorite cmdlets Get-ADReplicationAttributeMetadata. When I found this in the Windows Server 2012 beta it was like Christmas morning!

REPADMIN	PowerShell
	2012 Cmdlets
/FailCache	Get-ADReplicationFailure
/Queue	Get-ADReplicationQueueOperation
/ReplSingleObj	Sync-ADObject
/ShowConn	Get-ADReplicationConnection
/ShowObjMeta	Get-ADReplicationAttributeMetadata
/ShowRepl /ReplSum	Get-ADReplicationPartnerMetadata
/ShowUTDVec	Get-ADReplicationUpToDatenessVectorTable
/SiteOptions	Set-ADReplicationSite
	2008 R2 Cmdlets
/ShowAttr	Get-ADObject
/SetAttr	Set-ADObject
/PRP	Get-ADDomainControllerPasswordReplicationPolicy
	Add-ADDomainControllerPasswordReplicationPolicy
	Remove-ADDomainControllerPasswordReplicationPolicy
	Get-ADAccountResultantPasswordReplicationPolicy
	Get-ADDomainControllerPasswordReplicationPolicyUsage

The Script

Here is the PowerShell goodness we’ve been awaiting (also attached at the bottom of the post):

Import-Module ActiveDirectory            
            
$username = "janitor"            
$userobj  = Get-ADUser $username            
            
Get-ADUser $userobj.DistinguishedName -Properties memberOf |            
 Select-Object -ExpandProperty memberOf |            
 ForEach-Object {            
    Get-ADReplicationAttributeMetadata $_ -Server localhost -ShowAllLinkedValues |             
      Where-Object {$_.AttributeName -eq 'member' -and             
      $_.AttributeValue -eq $userobj.DistinguishedName} |            
      Select-Object FirstOriginatingCreateTime, Object, AttributeValue            
    } | Sort-Object FirstOriginatingCreateTime -Descending | Out-GridView

I realize that it looks complicated, but it is practically a one-liner. Notice the highlighted pieces:

You’ll need to provide a username in the appropriate variable. This can be a short user ID or a distinguished name.
The metadata cmdlet needs the switch ShowAllLinkedValues in order to return all of the group membership metadata. You only need this parameter with AD objects containing linked values.
Replace localhost with the FQDN of your nearest DC containing the user account in question.

Note that you will need a Windows Server 2012 domain controller and optionally the AD PowerShell module installed from the Windows 8 RSAT.

When you run this script you’ll get a clean grid view full of dated group memberships. If any groups are missing in the list, then they have likely not been converted to Linked Value Replication (LVR).

It would be easy to wrap this code into a function or module where you could reuse it for processing a large number of accounts. You could pipe a list of users into it, and then send the results to a CSV file. To scale it more efficiently you could simply dump the member metadata for every group in the domain instead of retrieving it multiple times for multiple users.

Do Your Part: Reduce Token Bloat Today

Armed with this code you can now begin the process of reviewing token bloat users and their group memberships. Hopefully the date information will empower you to remove them from some of those stale groups. Who knows, you might even be able to get by with a smaller key ring.

Active Directory PowerShell Notes From The Field

2012-09-15T05:00:00Z

PowerShell Saturday 002

Today I have the privilege of speaking at the second-ever PowerShell Saturday event. As a Microsoft Premier Field Engineer I get to meet many customers and help them with their Active Directory and PowerShell needs. I’ve taken some of that experience and wrapped it into a presentation called Active Directory PowerShell Notes From The Field.

The session includes these four topics:

Using Active Directory PowerShell to find schema update history
Using PowerShell to migrate DNS zones
Using Active Directory PowerShell to remediate token size issues caused by SID history
A brief look at what’s new in Active Directory PowerShell v3

These notes from the field come from scripting that I've done to assist customers with real-world needs. The purpose of the session is to demonstrate the power of PowerShell for automating Active Directory solutions for every-day scenarios AND to inspire you to learn PowerShell. To help with the learning part I have included several resources here for your reading pleasure.

Attached to the bottom of this post you will find a file containing the DNS sample code and a PDF of the PowerPoint presentation. You can view these files while you listen to the 75 minutes session recording here.

Resources

Code from the presentation

Schema Updates
DNS Migration - Attached at the bottom of this blog post.
SID History

Active Directory PowerShell Documentation

AD DS Administration Cmdlets in Windows PowerShell

TechEd 2012 Sessions on Channel9

Books

Automating Active Directory Administration with Windows PowerShell 2.0 (SYBEX) by Ken St. Cyr & Laura Hunter

PowerShell Saturday 001

If you would like to download the demos and audio recording of my presentation at the first PowerShell Saturday back in March you can find that here. In that session I covered Five Free Ways To Script Active Directory.