I have copied a checkout of a subversion (svn) repository and want to get rid of those hidden .svn folders. I know how to do this with FOR /R C:\Foldername %i IN (.svn) DO RD /S /Q %i in a cmd.exe box. Since I want to use PowerShell for daily tasks like this I need some help.

Try the following command line:

Get-ChildItem C:\Foldername -Include '.svn' -Recurse -Force | ?{$_.PSIsContainer} | %{Remove-Item $_ -Recurse -Force}

Just a side note: the export of a svn repository does not contain those .svn folders. Therefore, if you have access to the repository it is better to export it in order to have a unversioned stand-alone copy w/o .svn folders.

A few days ago, Ment van der Plas of Login Consultants released v 1.0 of his awesome App-V 4.5 Client Diagnostic and Configuration Tool, ACDC (download)

ACDC makes it possible for administrators or users to troubleshoot virtual applications on their App-V Client and the environment they run in:

• Launch predefined and custom commands within the virtual environment of each application.
• See the impact of the App-V Client and the available virtual applications on your system by calculating package size, cache size, user delta file size, log file size etc.
• Diagnose problems with App-V applications by parsing the App-V Client log file (in real time) and search any message online.
• Configure settings that are not visible in the App-V Client GUI, such as Predictive Streaming, Allow Stream from File , Max Package Age and many more.
• Give an overview of application and package information by merging important WMI, registry and OSD information in one single window.
• ACDC can be run both as an Administrator and as a Limited User. Running as a limited user will limit the functionality of the tool due to the fact that it has less permission on the system

At Login Consultants we have created a rather extensive scripting framework based on PowerShell scripts called Solution4. Conceptually it is similar to an earlier version of Solution4 which was based on CMD scripting and a collection of tools. The power of PowerShell, however, allowed us to improve this scripting framework even beyond our own dreams.

One of the key features of this scripting framework is that we standardize the automation and even more important, the way HOW automation is performed. This extensive standardization allows us to automatically document anything we do within this scripting framework. For our documentation efforts we chose Microsoft Word 2007 because it is, or will be, the most widely used word processor and because the COM interface is relatively straightforward.

The code snippets I will post in these series about PowerShelling Word 2007 are the functions I created to create items like paragraphs, tables and headings. At the end of these series I will put the complete script online for download.

First of all, lets get Word 2007 to run from PowerShell. Word 2007 exposes its methods through a COM interface. Starting an instance of Word 2007 in PowerShell is done like this:

$msWord = new-object -com Word.Application
$msWord.Visible = $true

This first line of code will start Word 2007 but it will be invisible to you. The second line will instruct Word 2007 to materialize. While this is already pretty cool, as you can see there’s no document. The next step is to open a new document like so:

$doc = $msword.documents.add()

The document created is based on the default template. If you want to base you new document on a different template, just tell Word. See:

$doc = $msword.documents.add(“D:\GenDoc\gendoc.dotx”)

Next time I will show you how to actually add some text.

There’s a lot of useful, proven VBScript functions and libraries out there and it is virtually impossible and maybe foolish to rewrite all that good stuff in Windows PowerShell.

They key to use VBS code in PowerShell is the COM object MSScriptControl that is designed to act as a script host. Within a PowerShell script, you can use this object to embed VBScript, e.g. load VBS code, call a function from it, pass arguments to it, and get its return values. Sounds cool? Yes, it is!

The function below – Load-VbsCode – passes VBS code to MSScriptControl and returns a code object with methods that represent the functions defined within the VBS code:

function Load-VbsCode
{
	param($vbsCode = $(throw "No VBS code specified."))

	$vbs = New-Object -ComObject MSScriptControl.ScriptControl
	$vbs.Language = "VBScript"
	$vbs.AddCode([string]::Join("`n", $vbsCode))
	$vbs.CodeObject
}

The AddCode() method expects a string. In order to prevent that an array of multiple text lines will be passed to the method, the data in $vbsCode will be converted to a string using Join.)

Let’s say that you have a VBS file called ConvertFunctions.vbs that, among others, contains this function:

Function Celsius(GradF)
	Celsius = (GradF - 32) * 5 / 9
End Function

The following example shows how to use the Load-VbsCode function in order to embed the above vbs code:

# get contents of the vbs file
$vbsCode = Get-Content .\ConvertFunctions.vbs

# pass the vbs code to Load-VbsCode
$vbs = Load-VbsCode($vbsCode)

# Ready to use the Celsius function...
$f = 70
$c = $vbs.Celsius($f)
Write-Host "$f Fahrenheit are $c Celsius."

Generally, with PowerShell 1.0 or newer, you can use ADSI to bind to an OU, and use its Create method to create a user in this OU:

$ou = [ADSI] "LDAP://ou=commandante,dc=cuba,dc=com"
$user = $ou.Create("User", "CN=Fidel Castro")
$user.Put("sAMAccountName", "fidelc")
$user.Put("userPrincipalName", "fidel.castro@cuba.com"
$user.SetInfo()

In Windows Server 2008 R2 it is possible to monitor and manage Active Directory with the “ActiveDirectory” Module for Windows PowerShell. (Read the MS TechNet article Active Directory Administration with Windows PowerShell.)

Generally, with PowerShell 1.0 or newer, you can use ADSI to bind to a domain, and use its Create method to create an OU in Active Directory:

# Create "Terminal Servers" OU in the root of the domain
$dom = [ADSI] "LDAP://dc=testdomain,dc=lab"
$ou = $dom.Create("OrganizationalUnit", "OU=Terminal Servers")
$ou.SetInfo()

And this creates a sub ou:

# Create "XenApp" OU under the "Terminal Servers"
$tsou = [ADSI] "LDAP://ou=Terminal Servers,dc=testdomain,dc=lab"
$xaou = $tsou.Create("OrganizationalUnit", "OU=XenApp")
$xaou.SetInfo()

It’s a good idea to create a function like below.

function New-ActiveDirectoryOU
{
	param(
		$ldapPath = $(throw "No ldap path specified."),
		$name = $(throw "No name for the new OU specified.")
	)
	$ad = [ADSI] $ldapPath
	$ou = $ad.Create("OrganizationalUnit", "OU=" + $name)
	$ou.SetInfo()
}

In Windows Server 2008 R2 it is possible to monitor and manage Active Directory with the “ActiveDirectory” Module for Windows PowerShell. (Read the MS TechNet article Active Directory Administration with Windows PowerShell.)

Interesting PowerShell presentation from Jeffrey Snover at the JAOO developer conference 2008:

Check out this presentation by Jeffrey Snover where he gets back to the basics and then work his way up. Great presentation to quickly understand the how and the why in PowerShell.

Check it out here

Read a very nice summary of the differences between the PowerShell 1.0 and PowerShell 2 CTP3 here

Dennis Damen’s ReconnAct! is a tool that adds the ability to run a command (executable or script) when a user disconnects from, or reconnects to a terminal server or VDI session. Furthermore it keeps track of the client’s ip address and the client’s name.

These day, I have read in Dennis Damen’s Blog that the new version is part of the Immidio Resource Kit.