Certified Microsoft Scripter? I vote for it. Read more at The Energized Tech’s Call to the Community for MCTS Scripting Certification

For years, I was trying over and over to get used to Microsoft Forums… I appeared there few times, however abandoned it after a while.

Major reason was that I either had to use web interface or Outlook Express to access it – web interface was not really user-friendly and NNTP was usually blocked at proxy servers, so I always left MS forums pretty soon…

Ok, I am sure that everyone around knows about this and is using it for many years, but I just discovered one really nice feature at Microsoft Forums – it supports RSS feeds

I am not sure when this feature was added, but FINALLY I can start being active at MS forums

Martin

Today I needed small function to determine what is the number of current week (usually referred as WeekOfMonth).

Code is very simple in fact:

Function Get-WeekOfMonth ([datetime]$Date = $(Get-Date)) {
	[int]$Day = $Date.Day
	Return [math]::Ceiling($Day / 7)
}

Martin

I was reading very interesting post from Jeffrey Hicks called PowerShell Picasso today and I must say that I agree with him 99%.

If you know the way I script, then you have probably noticed that it is hybrid code between PowerShell and .NET. For example I don’t like ForEach-Object cmdlet – from my perspective, it makes code much LESS readable. I would compare it to question sentence in English and in Spanish. In Spanish, every question sentence begins with question mark (for example ¿Cómo estás?) and you immediately know it is going to be the question.

For same reason, I always use ForEach ($X in $Y) {…}. I find it much easier to undestand $X. than $_… If I have a quick peek at code, using $Service.Status immediately tells me what I need, while $_.Status requires me to read preceding code to understand what type of object is $_. Organizing code to blocks is my preferred method (while many Powershell guys organize code to sentences ).

Second side effect is that by using .NET syntax, people much quickly adopt the fact that Powershell is based on .NET object and is object-oriented language. Later on, these administrators can read and understand MSDN documentation or examples that are written in C#. To summarize it, my point is that for many people, Powershell can be used as entry point to .NET world (.NET for Administrators).

I fully agree with rest of the Jeffrey’s article. “Problem” as I see it is that most people use Posh in interactive mode – and there is huge difference in writing few functions for yourself and trying to build complex framework out of Powershell (just checked – my framework currently consists of almost 4000 files, even though it is based on modules). In case you don’t think about readability of your code, you will get lost when you will need to write the complex modules (thousands of lines).

Martin

Surprisingly, official release of PowerShell 2.0 RTM for W2k3\XP\Vista was very silent, even official PowerShell blog didn’t mention it…. NOW we can finally start to ship all cool ideas that we delayed until v2 is officially RTMd

Anyway, you can find it as part of Windows Management Framework.

Martin

When working with local administrator account, there are 3 possible tasks you usually want to accomplish:

1.) Change password

2.) Rename account

3.) Disable\Enable account

Below are snippets of Powershell code that can help you to achieve that. First line is always used to retrieve local account with RID 500 (built-in administrator account, no matter what is the name), rest than depends on what you want to achieve.

1.) Change password

<P>$LocalAdministrator = $(Get-WmiObject –Query ‘Select * from Win32_UserAccount
Where (LocalAccount="True" and SID like "%-500")’)</P>
<P>$AdminReference = [adsi]("WinNT://./" + $LocalAdministrator.Name + ", user")
$AdminReference.psbase.invoke("SetPassword", "new and shiny password")</P>

2.) Rename account

<P>$LocalAdministrator = $(Get-WmiObject –Query ‘Select * from Win32_UserAccount
Where (LocalAccount="True" and SID like "%-500")’)</P>
<P>$LocalAdministrator.Rename("LocalAdmin")</P>
<P>$LocalAdministrator.Put()</P>

3.) Disable\Enable account

<P>$LocalAdministrator = $(Get-WmiObject –Query ‘Select * from Win32_UserAccount
Where (LocalAccount="True" and SID like "%-500")’)</P>
<P>$LocalAdministrator.Disabled = $False</P>
<P>$LocalAdministrator.Put()</P>

Martin

Henk Hofs – known as the geek with an opinion – has posted a nice PowerShell script to achieve ZTI functionality with Microsoft Deployment Toolkit 2010: ZeroTouch for MDT 2010 without SCCM!

During my recent investigation, I wanted to be sure that Powershell is really getting adopted and that it grows every year…

You can either try to get some results from companies like Gartner, but I usually don’t trust them too much. For me, best resource is of course Google

According to Google, we can see that interest in powershell is still growing:

I was also curious which countries are mostly interested in Powershell. Did you expect to see here U.S., UK, Germany or similar countries?

1. Russian federation

2. Norway

3. Czech republic

If you want to see report yourself, simply follow this link.

Martin Zugec

Hello again. This time I will share a small function that resides in my PowerShell profile script: grep. What is grep? grep is a text search utility originally written for Unix. The command name is an abbreviation for “global regular expression print”. The original grep – and my PowerShell grep function as well – searches files for lines matching a given regular expression and displays the matches in standard output.

Here comes the ready for use function…

function grep (
    $File = $(throw "Empty value for the File parameter."),
    $Pattern = $(throw "Empty value for the Pattern parameter."),
    [switch]$Recurse
) {
    if ($Recurse) {
        $Files = @(Get-ChildItem $File -Recurse)
    } else {
        $Files = @(Get-ChildItem $File)
    }
    if ($Files.Count -eq 0) {
        Write-Host "File(s) not found - $File"; return $null
    }
    $Results = $Files | Select-String -Pattern $Pattern
    if (!$Results) {
        Write-Host "No matches found in $File"; return $null
    }
    $Results | Format-List FileName,LineNumber,Line
}

Actually the grep function simplifies the usage of a command line like below:

PS C:\> gci c:\windows\windowsupdate*.log | Select-String "2009-12" | fl FileName,LineNumber,Line

Using grep you just need to type this:

PS C:\> grep -File C:\Windows\WindowsUpdate*.log -Pattern "2009-12"

Ah, almost I forgot to mention that the Select-String cmdlet is PowerShell’s grep.

Hello again! This time I share a quick tip.

MS-DOS and cmd.exe shell power users remember for sure how easy it was to write a script (or any other text file) quickly from the command line without an editor. It was possible to copy the CON device (which stands for Console meaning keyboard/input and monitor/output as one device) to a file, for example COPY CON TEST.CMD. Once a COPY CON command has been invoked, it was possible to type whatever you want, even multiple lines were possible. When completed you could save the file and return to the prompt by pressing CTRL-Z (or F6) which would create ^Z (end of file) and then press Return.

In PowerShell there’s a similar approach as well but it doesn’t correspond one-to-one. The trick takes advantage of a single-quoted here-string to create a script:

PS C:\Users\Pit> @'
>> "Hello, $Env:USERNAME!"
>> "There are $((Get-ChildItem).Count) files and folders in this directory: $pwd"
>> '@ > .\test.ps1
>>
PS C:\Users\Pit> type .\test.ps1
"Hello, $Env:USERNAME!"
"There are $((Get-ChildItem).Count) files and folders in this directory: $pwd"
PS C:\Users\Pit>
PS C:\Users\Pit> .\test.ps1
Hello, Pit!
There are 15 files and folders in this directory: C:\Users\Pit
PS C:\Users\Pit>

Actually, Here-strings are used to embed more or less large text blocks inline in scripts. Here-strings start with “@” plus double- or single-quote followed by newline and end with newline, double- or single-quote followed by “@” .