Last week I was a speaker at Tech Immersion 2011 here in Phoenix Arizona.  I gave four talks on a range of topics that covered Active Directory, PowerShell and Server Core.  Hopefully I have some new followers since the conference and if so make sure to say hi in the comments.

The highlight for myself was meeting Jeffrey Snover.  If you don’t know who he is then you better Bing or Google him now.  This is the father of PowerShell and now the Lead Architect for the Windows Server Division.  He was really great to talk, in fact there were a lot of great presenters there including, PowerShell gurus Don Jones & James Brundage, Microsoft Certified Master’s Miguel Wood & Mike Pfeiffer, MVPs and MCTs such as Simon Allardice, Scott Cate, Jeff Jones, Spike Xavier as well as Microsoft employees Michael Palermo, Harold Wong, Tony Harris & Kathrine Lord and ITIL/COBIT Master Mark Thomas.  I left one person out and that was on purpose.  Jason Helmick…what can I say.  He along with the rest of Interface Technical Training put on an excellent conference that will only grow more and more as time goes on.  Great job Jason and Lynn from Interface as well as everyone else that supported this event.

Here is a pic of Jeffrey and I after the event hanging out at Dick’s Hideaway.

I can’t wait for Interface to host another great event like this.

I love PowerShell.  The more I learn the better it becomes.

There are several versions of the Active Directory Schema available.  You must know what version you are running to fully understand the capabilities it allows for.  Below shows the different versions of the Active Directory Schema. The following link from MSDN should also update later versions.

Windows 2000 RTM = Schema version 13
Windows Server 2003 RTM = Schema version 30
Windows Server 2003 R2 RTM = Schema version 31
Windows Server 2008 RTM = Schema version 44
Windows Server 2008 R2 RTM = Schema version 47
Windows Server 2012 RTM = Schema version 56
Windows Server 2012 R2 RTM = Schema version 69
Windows Server 2016 RTM = Schema version 87

Now to see what version you are running just open up PowerShell (make sure you’ve loaded the native AD Cmdlets) and type the following:

Get-ADObject “cn=schema,cn=configuration,dc=domain_name,dc=local” -properties objectversion

Just check the objectversion results for the corresponding number above to check your schema version.

Time and time again I run into an issue that presents me with a SID which I need to resolve.  I’ve used a number of tools and scripts over the years to address this issue.  I think I have the best and easiest method for me to solve this issue that always seems to pop up.

If you’re new to PowerShell you will want to make sure you have it installed if you want to use this script…and yes it is a script not a command.  I do this by opening a text file and renaming it from a .txt file to a .ps1 file.  When you try to open a .ps1 file it may open in your text editor but for this you will want to Right Click it and select Edit which will open up whatever you have as your PowerShell editor.  Copy the following code into the Script Pane:

$objSID = New-Object System.Security.Principal.SecurityIdentifier
    ("S-1-5-21-768745588-123456789-987654321-500")
$objUser = $objSID.Translate( [System.Security.Principal.NTAccount])
$objUser.Value

Now just save this file and you can run it to return the results of the SID that you place in there.  The one thing that will change is the actual SID.  In this example i’m using S-1-5-21-768745588-123456789-987654321-500 which is the Well Known SID for the domain Administrator.  My results should show me the friendly name.  Anytime you change the SID you will have to resave the file but then just Run the script and it will show you the results.

I’m sure there is a way I could make this into an application but I”ll leave that fun for those looking to take this to the next step.

You may be familiar with the traditional ways to transfer FSMO roles but how about by using PowerShell?  By now you should just know that PowerShell can do everything the GUI can do…well at least that is the way it feels to me. 

If you want to use PowerShell to transfer any of your five FSMO roles (PDC Emulater, RID Master, Infrastructure Master, Domain Naming Master and Schema Master) then you will first need to import the Active Directory Module into PowerShell.

ipmo activedirectory

Now that you have the AD module loaded the cmdlet you will use for this is quite large – Move-ADDirectoryServerOperationMasterRole.  Thankfully we have the Get-help cmdlet to help us remember that.  All I need to do is remember move-ad and then I press tab to complete the rest.  There is only one other cmdlet that is similar to it and you just have to remember you are trying to move the FSMO role and not the sever.

When entering the cmdlet you need to specify the operation master roles to move. the syntax for the five roles are as follows – PDCEmulator, RIDMaster, InfrastructureMaster, SchemaMaster, or DomainNamingMaster. To specify more than one role just separate each role with a comma.

An example of me moving the RID Master and PDC Emulater to DC2 is as follows:

Move-ADDirectoryServerOperationMasterRole -Identity "DC2" -OperationMasterRole RIDMaster,PDCEmulator

A feature that I just love in PowerShell is the –WhatIf parameter.  By adding this to your code it will do a dry run and let you know what is going to change if you did the command without that parameter.

One key thing to note here is that I am NOT seizing the FSMO role.  For that you will need to use NTDSUtil as defined here.

Here are two ways for you to use PowerShell to raise your Forest Functional level to Server 2008 R2:

• get-adforest | set-adforestmode -forestmode windows2008R2Forest –confirm:$false
• set-adforestmode –identity netbiosname windows2008R2Forest –confirm:$false

Either way will work.  Enjoy

Tip of the day today is to view your Active Directory Tombstone period while using PowerShell

1. From a PowerShell prompt, type
2. (get-adobject "cn=Directory Service,cn=Windows NT,cn=Services,cn=Configuration,dc=AdminPrep,DC=Local" -properties "tombstonelifetime").tombstonelifetime

The result shows up in days…very cool. 

Just make sure to change dc=AdminPrep,DC=Local to match your domain.

Last night was the inaugural Arizona PowerShell user group meeting known as AZPOSH.  There was well over 20 people there and a great guest speaker.  Dr. Ferdinand Rios who is the CEO of Sapien Technologies spent an hour talking to us about what is new at Sapien…and wow there is some really cool stuff coming out soon.  Dr. Rios is a dynamic presenter and also a coder of some of their products.  He showed off an early alpha version of Visual Powershell which is perfect for a person like me that doesn’t like to remember (ok doesn’t have the mental capacity) a bunch of cmdlets and the ability to save portions of code for later use.  He also showed iPowerShell which is an app for iPhones as well as the iPad.  The future of that app (as long as it gets ported over to other phones) looks amazing.  The ability to use a device like the iPhone or iPad to run PowerShell remotely reminds me of the old Star Trek days.

Jason and Mike both did a great job running the meeting and I’m really looking forward to where this user group is going.  I know they are working on opening this up to a remote audience as well which is really intriguing for people that aren’t in the Phoenix area but still want to be part of the PowerShell community.  Jason suckered me in to presenting for the July meeting…actually I’m really excited to be able to speak about Active Directory and PowerShell.  Can’t wait to attend the next month’s meeting!!!

If you have been playing with the the AD PowerShell cmdlets you know that it requires a few things to run, first Windows Server 2008 R2 or Windows 7, the .NET Framework 3.5.1 and of course if you want to manage an AD domain you need Active Directory Web Services (ADWS) installed on at least one domain controller. 

By the way ADWS requires TCP port 9389

So how in the world does a Windows 7 system know how to find a DC running ADWS?  Well your client running PowerShell will use the normal DC locator process.  First the client will determine which site it is in nltest /dsgetsite and then it will determine the closest DC nltest /dsgetdc:<FQDN Domain>.  It is looking at the DC for the following flag:

DS_WEB_SERVICE_REQUIRED

More info on that flag can be found here.

Now what if you don’t have Server 2008 R2 DCs?  With Server 2003 and Server 2008 a problem occurs because the Net Logon service of those domain controllers does not recognize the DS_WEB_SERVICE_REQUIRED flag.  There are two hotfixes (one for what ever version of AD you are running) available to fix that in those environments.  Server 2003 and Server 2008

After you install this hotfix the AD PowerShell module and Active Directory Administrative Center will be able to locate DCs that have Active Directory Management Gateway Service installed, similar to Active Directory Web Services (ADWS) on a Windows Server 2008 R2-based computer.

Did I say free?  You bet I did.  Microsoft has done this for quite some time now and is something everyone should take advantage of.  Especially in today’s economy where training budgets are getting slashed. 

Here are three great labs that you can use to learn all about Server 2008 R2’s Active Directory. 

Windows Server 2008 R2: What”s New in Active Directory

Windows Server 2008 R2: Active Directory and Server Manager Remoting

Windows Server 2008 R2: Active Directory Recycle Bin, PowerShell V2, and Remoting

Do you have any cool free training resources?

With PowerShell 2.0 being released with Windows 7 and Server 2008 R2 there are plenty of fun stuff to do.  Although what I”m about to show you is not specific to PoSh 2.0 but it a great way to pull info from the Event Viewer.

When I’m presented with a problem on a server one of the first place I go is the Event Viewer.  Sure there are ways to filter it but I’d always wanted a way to dump that filter into another file to review later on another system.  PowerShell gives you a great method for displaying events as well as saving those results to a file.

The Event Log has several cmdlets available which can be seen here:

Get-EventLog
Clear-EventLog
Write-EventLog
Limit-EventLog
Show-EventLog
New-EventLog
Remove-EventLog

As you can see you can read an write to the Event Viewer here.  The Get-EventLog cmdlet is a favorite of mine.  With it you specify which Event Log to view and off you go.  Below is an example of using that command and showing how to only list the first 20 events.

Get-Eventlog -Logname System -Newest 20

Now if you want to save that you have several options.  You can save it as a text, htm or csv file.  Realize it may take awhile to build the whole file.  Below show the commands needed to output the files.

Get-Eventlog System | Out-file c:Tempsystem.txt
Get-Eventlog System | ConvertTo-html | Out-file c:Tempsystem.htm
Get-Eventlog System | ConvertTo-csv| Out-file c:Tempsystem.csv

The great thing is you don’t have to show everything.  If you want you can filter by the Event ID by using the –instanceid switch.  Below is an example.

Get-Eventlog System -instanceid 4 | Out-file c:TempEventID4.txt

As you can see PowerShell is really handy when it comes to EventLog management.  The best part is I haven’t even talked about Remoting.  You can use PowerShell to remote into other machines in your environment running PowerShell 2.  But that is another story…