Sorry for the long delay between posts, but work has been absolutely crazy.

Anyway, one of the recent tasks I have been working on is to find a way to check DFSR to make sure that our remote sites are properly replicating data back to our corporate datacenter.  Part of this new infrastructure relies heavily on Microsoft DFSR and all the cool stuff it brings (in 2003 R2).

Our support teams have been asking for ways to ensure that data has completely synchronized to our corporate datacenter every night.  Unfortunately there isn’t an easy way to determine this scriptomatically.  Well leave it to me to try some different things and attempt to put SOMETHING in place to do this.

Basically we have remote sites replicating during non-business-hours back to a central “hub” DFSR server.  We would then backup this “hub” server with our corporate backup infrastructure.  This is a WHOLE lot easier than getting users in remote sites to swap tapes or whatever and send them offsite, etc. 

The only way I have been able to determine the state of replication is to query the “backlog” of the remote site DFSR servers.  This should tell us how many files are sitting there awaiting replication. DFSRDIAG is a tool that can help us enumerate these files, but then we have to parse out the data.  We also need to know which replication partner, which replicated folder, and which replication group these remote sites belong to.

One way to enumerate that info is through a WMI query.  From the DFSR “hub” server you can enumerate all DFSR connections, groups, folders, etc. by running some queries against the “MicrosoftDFS” namespace.  This is different from standard WMI queries because the default namespace (cimv2) does not contain any DFSR configuruations.

Once we connect to this namespace, it is a fairly trivial task to cycle through all the connection partners, replication groups, and replicated folders.

We can then run the “DFSRDIAG” tool to see how many files are in the backlog.

Once we have determine how many files are out there for each replicated folder, we then write a custom event log entry and have our monitoring tools pick those up.

For this script I have set a threshold of 10 files before writing an “error” event log.  This can easily be changed based on your specific needs, though.  

You should also be able to easily customize the eventIDs and source information by modifying the values assigned to those variables.

For actually writing to the event log, I am “borrowing” some code my colleauge Mike put together.

Anyway, I think the script is fairly self explanitory.  If you need additionaly info or have questions, please let me know.

Thanks and happy scripting…

– Mark

## Check-DFSR.ps1 script
## Written by: Mark A. Weaver
## Site: http://www.vmweaver.com
## Version: 2.0
## Date: 5/7/2009
## Purpose: This script will query the local WMI root for DFS replication groups and folders.  
##				It will then run DFS utilities to determine the number of files in the backlog on the
##          destination partners in the replication group.
##          
##          This script was written for the spefic use of being run on a centralized DFSR server
##          which acts as the HUB for remote office backups.
##         
##        
##          Monitoring Rules can be setup to collect and report on the events being generated.
## 
##          Event information is written to the Application log using the EventIDs at the bottom.
## Input: None
#############################
## Updates:
##  20090408 Weaver: Fixed issue where multiple events are generated throughout the execution
##  20090408 Weaver: Added BacklogFileCount to event message
##  20090409 Weaver: Fixed list of replication connections issue due to change in replication topology
##  20090507 Weaver: Added functionality to return results from all partners in the replication
##
##
######################################################################
######################################################################
# Write-Event powershell function
# Written by Mike Hays
# http://blog.mike-hays.net
#
#
 
function Write-Event(
	[string]$Source = $(throw "An event Source must be specified."),
	[int]$EventId = $(throw "An Event ID must be specified."),
	[System.Diagnostics.EventLogEntryType] $EventType = $(throw "Event EventType must be specified. (Error, Warning, Information, SuccessAudit, FailureAudit)"),
	[string]$Message = $(throw "An event Message must be specified."),
	$EventLog
)
{
	#Uncommon event logs can be specified (even custom ones), but since that isn't generally
	#the desired result, I prevent that here
	$acceptedEventLogs = "Application", "System"
	if ($eventEventLog -eq $null)
	{
		$eventEventLog = "Application"
	}
	elseif (!($acceptedEventLogs -icontains $eventEventLog))
	{
		Write-Host "This function supports writing to the following event logs:" $acceptedEventLogs
		Write-Host "Defaulting to Application Eventlog"
		$eventEventLog = "Application"
	}
 
	#Create a .NET object that is connected to the Eventlog
	$event = New-Object -type System.Diagnostics.Eventlog -argumentlist $EventLog
	#Define the Source property
	$event.Source = $Source
	#Write the event to the log
	$event.WriteEntry($Message, $EventType, $EventId)
}
 
######################################################################
######################################################################
## Main 
## Errors written:
##   Log File: Application
##   Source: Check-DFSR Script
##   ID: 9500 - Lists fully replicated replication folders
##   ID: 9501 - Lists replication folders with less than the $BacklogErrorLevel files waiting 
##   ID: 9502 - Lists replication folders with more than the $BacklogErrorLevel files waiting
##   ID: 9503 - If a connection is not pingable, this event is written.
 
$BacklogErrorLevel = 10 
 
$ComputerName = $env:ComputerName
## Query DFSR groups from the local MicrosftDFS WMI namespace.
$DFSRGroupWMIQuery = "SELECT * FROM DfsrReplicationGroupConfig"
$RGroups = Get-WmiObject -Namespace "root\MicrosoftDFS" -Query $DFSRGroupWMIQuery
 
 
## Setup my variables
$ping = New-Object System.Net.NetworkInformation.Ping
$SuccessAudit = $Null
$WarningAudit = $Null
$ErrorAudit = $Null
$EventSource = "Check-DFSR Script"
$SuccessEventID = 9500
$WarningEventID = 9501
$ErrorEventID = 9502
$NoPingEventID = 9503
 
foreach ($Group in $RGroups)
{
	## Cycle through all Replication groups found
	$DFSRGFoldersWMIQuery = "SELECT * FROM DfsrReplicatedFolderConfig WHERE ReplicationGroupGUID='" + $Group.ReplicationGroupGUID + "'"
	$RGFolders = Get-WmiObject -Namespace "root\MicrosoftDFS" -Query $DFSRGFoldersWMIQuery
 
	## Grab all connections associated with a Replication Group
	$DFSRConnectionWMIQuery = "SELECT * FROM DfsrConnectionConfig WHERE ReplicationGroupGUID='" + $Group.ReplicationGroupGUID + "'"
	$RGConnections = Get-WmiObject -Namespace "root\MicrosoftDFS" -Query $DFSRConnectionWMIQuery	
	foreach ($Connection in $RGConnections)
	{
 
		$ConnectionName = $Connection.PartnerName.Trim()
		$IsInBound = $Connection.Inbound
		$IsEnabled = $Connection.Enabled
 
		## Do not attempt to look at connections that are Disabled
		if ($IsEnabled -eq $True)
		{  
			## If the connection is not ping-able, do not attempt to query it for Backlog info
			$Reply = $ping.send("$ConnectionName")
			if ($reply.Status -eq "Success")
			{
 
 
				## Cycle through the Replication Folders that are part of the replication group and run DFSRDIAG tool to determine the backlog on the connection partners.
				foreach ($Folder in $RGFolders)
				{
					$RGName = $Group.ReplicationGroupName
					$RFName = $Folder.ReplicatedFolderName
 
					## Determine if current connect is an inbound connection or not, set send/receive members accordingly
					if ($IsInBound -eq $True)
					{
						$SendingMember = $ConnectionName
						$ReceivingMember = $ComputerName
					}
					else
					{
						$SendingMember = $ComputerName
						$ReceivingMember = $ConnectionName
					}
					   $Out = $RGName + ":" + $RFName +  " - S:"+$SendingMember + " R:" + $ReceivingMember 
					   Write-Host $Out
						## Execute the dfsrdiag command and get results back in the $Backlog variable
						$BLCommand = "dfsrdiag Backlog /RGName:'" + $RGName + "' /RFName:'" + $RFName + "' /SendingMember:" + $SendingMember + " /ReceivingMember:" + $ReceivingMember
						$Backlog = Invoke-Expression -Command $BLCommand
 
						$BackLogFilecount = 0
						foreach ($item in $Backlog)
						{
							if ($item -ilike "*Backlog File count*")
							{
								$BacklogFileCount = [int]$Item.Split(":")[1].Trim()
							}
 
						}
 
 
						if ($BacklogFileCount -eq 0)
						{
							#Update Success Audit 
							$SuccessAudit += $RGName + ":" + $RFName + " is in sync with 0 files in the backlog from "+ $SendingMember + " to " + $ReceivingMember +".`n"					
 
						}
						elseif ($BacklogFilecount -lt $BacklogErrorLevel)
						{
							#Update Warning Audit
							$WarningAudit += $RGName + ":" + $RFName + " has " + $BacklogFileCount + " files in the backlog from " + $SendingMember + " to " + $ReceivingMember + ".`n"
						}
						else
						{
							#Update Error Audit
							$ErrorAudit += $RGName + ":" + $RFName + " has " + $BacklogFilecount + " files in the backlog from " + $SendingMember + " to " + $ReceivingMember + ".`n"
						}
						#Write-Host + $Folder.ReplicatedFolderName "- " $BackLogFilecount -foregroundcolor $FGColor
					}
				}
				else
				{ 
				Write-Host $ConnectionName "is not pingable" 
				$NoPingMessage = "Server """ + $ConnectionName + """ could not be reached.`nPlease verify it is on the network and pingable."
				Write-Event $EventSource $NoPingEventID "Warning" $NoPingMessage "Application"
				}
			}
 
	}
 
}
## Write my events to the local Application log.
 
if ($SuccessAudit -ne $Null)
{
	Write-Event $EventSource $SuccessEventID "Information" $SuccessAudit "Application"
}
 
if ($WarningAudit -ne $Null)
{
	Write-Event $EventSource $WarningEventID "Warning" $WarningAudit "Application"
}
 
if ($ErrorAudit -ne $Null)
{
	Write-Event $EventSource $ErrorEventID "Error" $ErrorAudit "Application"
}

Okay, so this is the second installment of my little tutorial-thingy for Powershell.  After much thought on where I want this to go, I figured the next logical step would be to talk about setting up your Powershell (“PoSh”) environment.

So, let’s put together a little laundry-list of tools you may want to procure.  Just download the bits and save them for later.  We will go through some of these in more detail.

1. Powershell installation bits (requires at least .NET 2.0 Framework)
2. PowerTab from ThePowerShellGuy (Most EXCELLENT Site for all things PoSh)
3. Quest PowerGUI (A powerful FREE GUI and IDE for PoSh) I won’t cover this installation here, but it is pretty straight forward.

That will probably be enough to get moving.

The Powershell install should be fairly straight forward.  Just take all the default options and let-her-role.

NOTE: If you want to install a newer version of Powershell, you will need to Uninstall the previous version.  This is kinda sucky, but not too bad.  To Uninstall it, you can go to Add/Remove Programs and look for it, but you may not see it if you have “Show Updates” option off.  It probably will show up as “Window Powershell”.

To install PowerTab, unzip the downloaded file to a folder you want it to live permanently.  I normally pick something like “C:\Program Files\PowerTab” so it is where all my other programs live.

Now open a command shell and start Powershell by typing in “powershell” and hitting Enter.

This may take a few seconds to launch, but if successful you should see your new and shiny Powershell prompt.   The first thing to do before anything else make it so we can actually run scripts.

Out-of-the-box, Powershell is delivered secure.  SO secure, in fact, that you can NOT run ANY scripts without making it a little less secure.  I will probably discuss this in more detail later or pressure my buddy Mike to write about it on his blog (this is more up his alley than mine).

Anyway…at your PoSh prompt type in the cmdlet:

Set-ExecutionPolicy RemoteSigned

If successful, you should be kicked back to your prompt.  Now we can move forward with the PowerTab install.

CD to the directory you install PowerTab to and run the “Setup.CMD” file to start the installer.  I normally just take all the defaults and let it go.  This will probably take a few minutes to finish up.

Now to show you a little about what PowerTab does for you….

If you type “Get-” and then hit the TAB key you should see a popup window with all sorts of fun things.  Basically PowerTab is like tab completion on STEROIDS.  It is very helpful for discovering what is available and such.  I hope you will take this opportunity to explore Powershell a bit.

You can get a list of all commands (called Commandlets) by typing in “Get-Command”.

I guess that is a fairly good place to break and talk about the “Cmdlets” (said CommandLets).

Cmdlets are the meat-and-potatoes of Powershell.  They are to Powershell what “cd” and “dir” are to the normal Windows command shell (cmd.exe).  Cmdlet names are constructed of 2 parts: a VERB and a NOUN.  If you look at the output of the “Get-Command” cmdlet, you will see lots of verbs on the left side of the “dash” in the cmdlet name: “Get”, “Out”, “Write”, etc.  The right side of the cmdlet name is the noun, or the thing that the verb acts on.

As you can see there are common Verbs and Nouns.  You can, in fact, do a “get-command -verb get” to list all commands that have the verb “Get”.  You can do the same for Nouns.  Go ahead and try that out on a few.

There are several cmdlets you should be using as you are learning the ins and outs of Powershell.  Probably the MOST helpful is, well “Get-Help”.

Get-Help is one I use on a VERY regular basis.  The general format for this one is:

• “Get-Help <Cmdlet>”    : Gives basic info on the cmdlet
• “Get-Help <Cmdlet> -Detailed”  : Gives  MUCH more info about the Cmdlet including some examples on using the cmdlet
• “Get-Help <Cmdlet> -Full” : I think this gives ALL the info about the Cmdlet
• “Get-Help <Cmdlet> -Examples” : Just gives you the usage examples.

Go ahead and try it now.  Do a “get-command”,  pick one that looks interesting to you and “get-help” on it.  This was crucial for me in learning the Powershell.

While I bring this part to a close I will challenge you to write something…well ANYTHING really.  The best way for me in learning was to pick a task and do it in Powershell.  The thought process for me was “Well, I could do this in vbScript in like 5 minutes, or I could take 30 minutes and do it in Powershell and learn a ton.”  If I have the time to do it in Powershell, I am doing it.

Some simple tasks would be to start using Powershell as your “normal” command shell.  This will get you used to using the cmdlets to navigate the environment and doing things.  Try NOT to use some of the default aliases that are “replacements” for the standard “cmd.exe” commands. These would include “type”, “dir”, etc.  I have been using the Powershell equivilant aliases…  “dir” becomes “Get-ChildItem” or simply “gci”.

The other thing I will challenge you to look at is the cmdlet “Get-Member”.  This will help you in this worthwhile venture into the wonderful world of Powershell.

I think the next session we will cover the notion that Powershell is “Object-Based”, which will be a good lead in from your “homework” on the “Get-Member” cmdlet.

Anyway, until next time…. happy Scripting!

– Mark

This will (hopefully) be the first of several ‘tutorials’ on Powershell.

Many of you have probably seen code in the forums or tutorials online that show some exerpts of code that are just CRAZY!  Many containing aliases like “%” and “?” and lots of braces and parentheses of all shapes and sizes.

Well, one of the things I love about Powershell is that you can do some VERY powerful, yet hard-to-read things at the command line.  While this may seem super and efficient for someone who knows Powershell, it SUCKS if you are trying to learn the language.

When I was trying to pick it up, this is all you could really find and it wasn’t until I found (what I believe to be the Powershell BIBLE) Windows PowerShell in Action by Bruce Payette.

In my mind there are ideally two different styles to Powershell(ing).

• The free-form, Wild-Wild-West,  I-need-to-pound-this-out  command line style
• The structured, methodical, EXPLICIT scripting style

From a practical sense, though, I think most people end up somewhere in the middle.  What absolutely drives me bonkers is obscure-one-liners that veteran Powershell scripters spew to  the newbie scripters asking relatively simple questions like:

“How  do I get a list of all files in a directory that have been modified in the last 3 weeks?”

One may be inclined to say “Oh, that’s easy!  Here it is…”

gci |sort| %{if ($_.LastWriteTime -GT (get-date).Adddays(-21)) `
{write-host $_.name "--"  $_.LastWriteTime -foreground Red}}

But for someone unfamiliar with Powershell, it looks like a bunch of gibberish.  Now something like THIS may be more helpful for them:

$AllFiles = Get-ChildItem | Sort-Object
$Now = Get-Date
$CutoffDate = $Now.AddDays(-21)
Foreach ($File in $AllFiles) {
     If ($File.LastWriteTime -gt $CutoffDate)
     {
      Write-Host $File.Name "--" $File.LastWriteTime -Foreground Red
      }
  }

Okay, if someone is asking this question, they are certainly new to the language and so an obscure response will probably only confuse them and, hopefully, not taint their desire to learn this robust and relatively simple tool.

ANYWAY… sorry about that half rant/half informational bit…Let’s talk a little bit about Powershell…

What *IS* Powershell?

Well the quick-and-dirty is that it is a “new” scripting language and command shell geared for IT administrators with a focus on simplicity, power, and automation.

The “official” description can be found here: http://www.microsoft.com/windowsserver2003/technologies/management/powershell/default.mspx

Anyway, now that you have an idea of what Powershell is, we will take a peak at some of the easy stuff you can do with it.  I will probably start with some of the fundamentals of scripting and move forward from that.

That’s all for now, but I will write more shortly.  I still haven’t figured out what format I want to use, but we will figure it out together.

Thanks for reading, sorry for the mild rant, and happy shelling!

– Mark