Crazy stuff in some logging

Doing some troubleshooting on a (Altiris) PXE server i found a weird line of code in a log:

 

 

i did a search and found this:

http://en.wikipedia.org/wiki/Hexspeak

http://www.urbandictionary.com/define.php?term=dead%3Abeef  apparently this line of code is used in IPv6 communication

this also has another meaning: http://en.wikipedia.org/wiki/Magic_number_%28programming%29#Magic_debug_values apparently these codes were used in IBM RS6000 and the Original MAC OS. could this be some code was re-used? ...

Start MDT Litetouch deployment remote

Hello again, i am back with a script that is quite handy for IT deployments done with MDT (any version would actually work with this script)
So Microsoft made MDT to be integrated with SCCM and, if done correctly, that combination is very powerful to deploy any kind of Microsoft OS to the enterprise, but what about the smaller clients, the ones who don’t have SCCM? MDT can be used on its own and Litetouch deployments can do the trick!
There is one little thing though that has not properly been addressed by the MDT development team (at least that's my opinion) and that is to hand us a way to get deployments started remotely from the Administrators console. As always with these kind of things i am not the only one so on TechNet a thread was started to get this issue addressed.
Handed solutions were two: present a batch file with a link to the litetouch.vbs and use psexec.exe to get a deployment started remotely. (Psexec is a formidable tool, part of the sysinternals Pstools toolkit)  i have used the first one many times before but its drawbacks are: most of the time you have to log on to the remote deployment system. the Psexec solution however is really nice, that's what i used as a base for this script.
                                
figure 1 the batched solution                                                         figure 2 the Psexec solution
The main difference is: the batched (first) solution is one in which the clients have to fetch the litetouch scripts by themselves, the second Psexec solution is the other way around, in this case you bring the litetouch.vbs script to the client.

---

$ErrorActionPreference = "SilentlyContinue"
Do {
Clear-Host
Do {
$trgMachine = Read-Host("Give the machinename that has to receive a LiteTouch deployment (Netbios or DNS name are equally good)")
    If($trgMachine -eq ""){Write-Host "Please give a name"}
}While($trgMachine -eq "")
psexec.exe -i \\$trgMachine -h -u DOMAIN\User -p Userpassword cscript.exe //B "\\MDTServer\Deploymentshare$\Scripts\litetouch.vbs"
   if($LASTEXITCODE -eq 0){Write-Host "All went well"}else{Write-Host "Something went wrong: " + $LASTEXITCODE}
 
$goOn= Read-Host("Another machine? (y)")
}while($goOn -eq "y")

---

Some explanation: the main line of the script is the line starting with psexec.exe it will run the command starting at cscript.exe on the remote machine (designated by $trgMachine) under credentials of the given –u Username and (optional) –p password (this gets sent in clear text so you can omit the –p option and give a password any time in the command shell when running the script) then there are some Do – While loops will restart the script when an empty hostname is found and at the end of a run. the option -h in the psexec line will suppress any UAC prompt (provided you started the script with an account (the -u option) that has local administrator rights)
To use the script, make sure you have psexec.exe installed on a location that's in one of the path locations (usually C:\Windows\System32 is a good location)
have fun and see you next time

A handy EventLog Reader with Powershell

Tags van Technorati: Powershell,eventlog,reader,Get-Eventlog,use Microsoft form with powershell
So here i am back with another handy script for the IT administrator.

Question: are you, like me, fed up with the tedious way Microsoft event log are to be retrieved and viewed? then i might have a (PowerShell) solution for you!

In this script i have taken some AD PowerShell plugin functions and combined it with a few .Net forms. (thanks to a post on Microsoft TechNet_ furthermore i added Get-Eventlog Cmdlet to derive any eventlog content from any machine you can access in one script. the script fetches only the first n (asked in the script “how many lines”) recent Errors or failures.

---

# this script reads eventlog from any Computer you can access
# Script build by Bas Huygen February 2013
# the MS forms procedures are from Microsoft: http://technet.microsoft.com/en-us/library/ff730941.aspx
$ErrorActionPreference = "SilentlyContinue"

Do{
# Procedure 1: Get all AD computers and make a selection by filtering it
Clear-Host
$compfilter = Read-Host("please make a selection of computers, this can be one name or a range by the use of * (wildcards)")
If($compfilter -eq ""){$compfilter = "*"}
$allcomps = Get-ADComputer -filter * |Select-Object Name |Sort-Object name |where {$_.name -like "$compfilter"}

# Procedure 2: Select a computer in a form
[void] [System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")
[void] [System.Reflection.Assembly]::LoadWithPartialName("System.Drawing")

$objForm2 = New-Object System.Windows.Forms.Form
$objForm2.Text = "Select a Computer"
$objForm2.Size = New-Object System.Drawing.Size(300,200)
$objForm2.StartPosition = "CenterScreen"

$objForm2.KeyPreview = $True
$objForm2.Add_KeyDown({if ($_.KeyCode -eq "Enter")
{$x=$objListBoxcmp.SelectedItem;$objForm2.Close()}})
$objForm2.Add_KeyDown({if ($_.KeyCode -eq "Escape")
{$objForm2.Close()}})

$OKButton2 = New-Object System.Windows.Forms.Button
$OKButton2.Location = New-Object System.Drawing.Size(75,120)
$OKButton2.Size = New-Object System.Drawing.Size(75,23)
$OKButton2.Text = "OK"
$OKButton2.Add_Click({$x=$objListBoxcmp.SelectedItem;$objForm2.Close()})
$objForm2.Controls.Add($OKButton2)

$CancelButton2 = New-Object System.Windows.Forms.Button
$CancelButton2.Location = New-Object System.Drawing.Size(150,120)
$CancelButton2.Size = New-Object System.Drawing.Size(75,23)
$CancelButton2.Text = "Cancel"
$CancelButton2.Add_Click({$objForm2.Close()})
$objForm2.Controls.Add($CancelButton2)

$objLabel2 = New-Object System.Windows.Forms.Label
$objLabel2.Location = New-Object System.Drawing.Size(10,20)
$objLabel2.Size = New-Object System.Drawing.Size(280,20)
$objLabel2.Text = "Please select a computer:"
$objForm2.Controls.Add($objLabel2)

$objListBoxcmp = New-Object System.Windows.Forms.ListBox
$objListBoxcmp.Location = New-Object System.Drawing.Size(10,40)
$objListBoxcmp.Size = New-Object System.Drawing.Size(260,20)
$objListBoxcmp.Height = 80

# loop through all compyters filtered out of the AD in procedure 1
ForEach ($c in $allcomps){[void] $objListBoxcmp.Items.Add($c.name)}

$objForm2.Controls.Add($objListBoxcmp)

$objForm2.Topmost = $True

$objForm2.Add_Shown({$objForm2.Activate()})
[void] $objForm2.ShowDialog()

$trgHost = $objListBoxcmp.Text

# Procedure 3: Select an Eventlog Source in a form
#[void] [System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")
#[void] [System.Reflection.Assembly]::LoadWithPartialName("System.Drawing")

$objForm = New-Object System.Windows.Forms.Form
$objForm.Text = "Select an Eventlog Source"
$objForm.Size = New-Object System.Drawing.Size(300,200)
$objForm.StartPosition = "CenterScreen"

$objForm.KeyPreview = $True
$objForm.Add_KeyDown({if ($_.KeyCode -eq "Enter")
{$x=$objListBox.SelectedItem;$objForm.Close()}})
$objForm.Add_KeyDown({if ($_.KeyCode -eq "Escape")
{$objForm.Close()}})

$OKButton = New-Object System.Windows.Forms.Button
$OKButton.Location = New-Object System.Drawing.Size(75,120)
$OKButton.Size = New-Object System.Drawing.Size(75,23)
$OKButton.Text = "OK"
$OKButton.Add_Click({$x=$objListBox.SelectedItem;$objForm.Close()})
$objForm.Controls.Add($OKButton)

$CancelButton = New-Object System.Windows.Forms.Button
$CancelButton.Location = New-Object System.Drawing.Size(150,120)
$CancelButton.Size = New-Object System.Drawing.Size(75,23)
$CancelButton.Text = "Cancel"
$CancelButton.Add_Click({$objForm.Close()})
$objForm.Controls.Add($CancelButton)

$objLabel = New-Object System.Windows.Forms.Label
$objLabel.Location = New-Object System.Drawing.Size(10,20)
$objLabel.Size = New-Object System.Drawing.Size(280,20)
$objLabel.Text = "Please select an Eventlog source:"
$objForm.Controls.Add($objLabel)

$objListBox = New-Object System.Windows.Forms.ListBox
$objListBox.Location = New-Object System.Drawing.Size(10,40)
$objListBox.Size = New-Object System.Drawing.Size(260,20)
$objListBox.Height = 80

[void] $objListBox.Items.Add("System")
[void] $objListBox.Items.Add("Application")
[void] $objListBox.Items.Add("Security")

$objForm.Controls.Add($objListBox)

$objForm.Topmost = $True

$objForm.Add_Shown({$objForm.Activate()})
[void] $objForm.ShowDialog()

$evtLog = $objListBox.Text
$howmany = Read-host ("How many lines should i fetch? (blank fetches 25 lines)")
If ($howmany -eq ""){$howmany = 25}
If($evtLog -eq "Security"){$errtype = "failureaudit"} else{ $errtype = "error"}
# now get the eventlog from the selection
Get-EventLog -ComputerName $trgHost $evtLog -Newest $howmany -EntryType $errtype
Get-EventLog -ComputerName $trgHost $evtLog -Newest $howmany -EntryType $errtype | group-object -property source -noelement |
sort-object -property count -descending

$erID = Read-Host("Zoom in to a specific event? (give IDnumber)")
If($erID -eq ""){}else{Get-EventLog -ComputerName $trgHost $evtLog -Newest $howmany -EntryType $errtype |?{$_.Index -like $erID} |select Message}
$again = Read-Host("Start again? (y)")
}while($again -eq "y" -or $again -eq "Y")

---

its output will like something like this:

Have fun, comments are welcome and till next time!

Simple Connectivity Script

In the last weeks i have spent a lot of time coding Powershell scripts. In the next few days i will share some of them because i think they have added value to the Powershell community.
This script will test AD computers (one or a whole range) on connectivity and return its state in green (when the machine is up) or red (when the machine is down) its core provider is the Active Directory module of powershell and the Test-Connection cmdlet that basicly tests a connection with a ping.

---

#  This script tests the connectivity of Active Directory computers
# Script built by Bas Huygen februari 2013
# The usefull variable ErrorActionPreference is used to control the feedback Powershell returns to the ‘default-out’ $ErrorActionPreference = "SilentlyContinue"
# we’re clearly using the AD module here…
Import-Module ActiveDirectory
Clear-Host
$inp = Read-Host "give the name of the machine that has to be checked `n
It is also possible to use a wildcard (*) to test a range of computers`n
For example giving SER* will test all AD computers starting with a name like SER01 or SERvertest `n
not providing a value here will input * which means all AD computers will be scanned"
If($inp -eq ""){$inp = "*"} $ir = 0; $is = 0
foreach($comp in (Get-ADComputer -filter *  |where {$_.Name -like $inp})){`
If(Test-Connection -Count 1 $comp.name){$ir ++ ;Write-Host "Machine "  $comp.name  "is up-and-running" -ForegroundColor Green}`
Else{$is ++;Write-Host "Machine " $comp.name "is down" -ForegroundColor Red}}
Write-Host "---------------------`n"
Write-Host "total running machines is" $ir -ForegroundColor Green
Write-Host "total stopped machines " $is -ForegroundColor Red

---

output looks like this:
have fun with it and questions, please leave them at this page and i will get back to you.

PowerShell, the key to survival (of the fittest IT person)

So i have had my fair share of PowerShell for the last years. You might think that would be enough to open my eyes for the the sheer power of this Shell and embracing it right?
Wrong! it so turns out that me and most of my IT colleagues tend to keep their every day work and working habits preferably as-is. what this means is that most IT administrators i know stick to the stuff they know by heart. This is, off course, quite human and tends to keep our species on top of the hill (figuratively speaking, and mind you, by species i mean IT professionals) but in this case i have come to realize it is not necessarily so.  What’s that you say?  yes, we IT admins as we are today have to keep our knowledge up to date and, as always, we tend to learn a lot of quickly expiring information and working methods.
I have always wondered why i had to put such a tremendous amount of effort into learning IT- and IT related stuff, since my exposure to PowerShell it think i got it now.
So what’s the matter? take a look at the picture below, it depicts the evolution of IT for the last 20 years. beginning in the nineties (the time IT became to be a business) we IT admins were using mainly command-line interpreters like DOS, KSH and BASH. these shells were fairly limited compared to the vast amount of IT possibilities of today but at that time it was good enough to do the general stuff. In those days networks were fairly local and definitely smaller then today so there was little need for complex operations via networks.

Growing IT and its pitfalls

since the beginning of this century IT has grown enormously and, as always, this tends to come with some start-up problems. with the growth of the networks and connections to extranets (via Internet) it became clear the old fashioned admin tools were quickly growing obsolete. the main problem with those tools was its ‘ reach’  most of them were meant to be used only locally on the machine that hosted the service. as soon as remote systems became fashion these kind of tools became obsolete and limited.

IT anno 2013

speaking of now, the IT has grown into two ‘ camps’  one being the client side, the other being the server side. as far as we can see now, the client side will continue to expand into a large ‘collection of diversity’ comprising of all kind of devices that can, at least, connect to the internet via WLAN or 3G and in the near future 4G. managing these devices is not done because today many people also use their own device for their work and because of the sheer diversity of the operating systems these devices use.
the server side, however, is more uniform, some reasons for this are: servers are mainly owned by large IT providers, are end user unfriendly mainly because of their user interface and the characteristic of the server device hence the focus of the management of IT functionality on the server side.

What has this got to do with PowerShell?

Combining all things written before results into one notion:  how do i as IT admin keep on going using as little effort as possible? PowerShell!! let me tell you why i think this is the only valid way to go:

PowerShell main strength

Learning all this stuff to get to this point in my career has learned me one thing in general: learn as much of those things in IT of which ‘ all digital things are made of’ or in other words: figure out what is the most important and central ‘object’ in IT and learn about its features; characteristics and its use. what’s that? its the Object. since programmers began to work with Objects in a constructive way the IT has gone sky-high so that’s what i should be learning. long story short: PowerShell is entirely focused on Objects. It has the capacity to manage a whole range of objects concerning their number of devices and their OS management, more and more libraries are written to manage more then Windows Machines alone.

Why PowerShell

The reason i chose PowerShell is threefold: first PowerShell is a new kind of shell: it is not a shell that only uses text as main operator; no PowerShell does way more; it is a way to directly interact with Objects, in this way PowerShell can do many things more and faster than its text based cousins. the second reason is that it is quite easy to learn and incorporates quite a bit of ‘ old fashioned commands and methods’  used in many scripting languages as we know. the third reason is: PowerShell is not limited to a few commands; NO PowerShell is expandable so it is really the one and only way to go.

PowerShell has a clear Future

Because PowerShell is comprised of a language directly interacting with Objects (through the use of Microsoft .Net) its use and methods will be things you learn once and will continue to use in the future; knowing how to write commands and scripts is the way we as IT Admins will continue to evolve; Yes! we have a future now!

Tags van Technorati: IT,Powershell,Learning IT,Managing IT,IT future