Hier das minimalistische Script für TortoiseSVN 1.9.4:

<appdefinition>
<file>TortoiseSVN-1.9.4.27285-x64-svn-1.9.4.msi</file>
<hash type="SHA256">7CAD40E63FF5400483F853642477AD17C88177A530C053EA307243E17C6192DC</hash>
<info>
<setupType>MSI</setupType>
<isX86>false</isX86>
</info>
<install/>
<uninstall/>
<detection/>
<dependency/>
<supersedence>
<deploymentType uninstall="false" type="SHA256">0D3894C8B0E6F116C34408E87C645757E9B568ABCCE3C9FCEA42076FA7A01293</deploymentType><!--TortoiseSVN-1.8.11.26392-x64-svn-1.8.13.msi-->
<deploymentType uninstall="false" type="SHA256">5059209B24972D978E80AFCAC1721AAFB560C42C59ED193689EEE23563D23850</deploymentType><!--TortoiseSVN-1.9.3-->
</supersedence>
</appdefinition>

In einigen Fällen möchte man eine langsamere Verbindung simulieren. Mittels Netzwerkeinstellungen der virtuellen NIC in Hyper-V könnte eine Drosselung schon umgesetzt werden. Dies simuliert aber keine Paketverluste und was ist, wenn man das Host System (z.B. für Hyper-V replica Tests) einschränken möchte?

Eine alte und immer noch funktionale Lösung ist WANem. Es handelt sich dabei um eine Live-CD (knoppix) die einfach in eine VM eingelegt wird. Die VM ist mit 1GB RAM, einer NIC und keiner Platte ausgestattet. Die NIC sollte eine legacy NIC sein, da diese automatisch erkannt wird. In meinem Hyper-V 2012 R2 Preview hat die “neue” 3.0 Beta nicht funktioniert. Die ältere 2.3 funktioniert und reichte von den Featuren aus.

Den Agent gibt es wie üblich in einer 32bit und 64bit Variante und liegt als MSI File vor. Er installiert einen Dienst “User Experience Virtualization service” mit dem internen Namen UevAgentService. Dieser Dienst agiert als Dateisystem Filtertreiber.

Eventlognachrichten landen Windows 7 typisch in ein eigenes Eventlog unter “Applications and Services Logs/Microsoft/User Experience Virtualization/Logging” in Admin und Operational.

Ein eigene Oberfläche hat der UE-V Agent (noch?) nicht. Die Steuerung erfolgt über WMI. Für die WMI Schnittstelle wird zusätzlich ein Powershell Modul installiert, dass über “Import-module Microsoft.UEV.commands” in eine Powershellsitzung importiert werden kann.

Hi, I had a question where you can find the settings for the automatic forwarded alerts to nagios in SCOM. You can find it here:

1. Administration Pane

2. Product Connectors –> Internal Connectors

3. Select the Nagios Connector

4. Properties

5. There you can add or edit subscription (the wizard is like the Notification Subscription Wizard)

Here is a screenshoot:

Eine Überschrift aus nur zwei Abkürzung. MDOP (Microsoft Desktop Optimization Pack) dürften die meisten bereits von App-V kennen. Und UE-V soll genau ein “Schmerz” von der Applikationsvirtualisierung lösen. Durch App-V wird eine Anwendung in einer (relativ) isolierten Blase ausgeführt. Dies bezieht sich auch auf Einstellungen, die der Benutzer speichert. Diese werden in einer Containerdatei im Profil hinterlegt. Startet er die Anwendung danach z.B. virtuell auf einem Terminalserver, so wird diese Containerdatei wieder herangezogen und er findet seine Einstellungen wieder vor. Sobald er aber die Anwendung in physikalisch installierter Form startet sind diese Einstellung nicht da, da sie nur in der virtuellen Blase zur Verfügung stehen.

Wird Software in Enteo per statischen Gruppen zugeordnet, so ist es bei einem Hardwareaustausch notwendig, die Zuordnungen des alten PCs auf den neuen zu übertragen. Dies kann man natürlich durch manuelles Drag&Drop machen, oder aber über ein kleines Powershell Skript:

param([string]$sourcename="source", [string]$targetname="target")
Add-PSSnapin NwcServices.BlsAdministration
$server="\\enteoserver"
New-PSDrive -Name emdb -psProvider BlsEmdb -Root $server
cd "emdb:\rootdse"
$source=get-emdbcomputer -recurse $sourcename

if ($source)
{
    $target=get-emdbcomputer -recurse $targetname
    if ($target)
    {
        $source.GetAssociatedItems() | where {$_.SchemaDisplayName -eq 'Static Group'} |foreach-Object{
        write-host "Cloning group " $_.Name " from $sourcename to $targetname"
        $_.addMember($target)
        }
    }
    else
    {
        write-host "Target $targetname cannot be found!"
    }
}
else
{
    Write-host "Source $sourcename cannot be found!"
}

Das Skript selber ist recht einfach aufgebaut. Es wird der Quellcomputer gesucht und das Objekt abgefragt, welche Verbindungen es hat.
Diese Verbindungen werden nach dem Typ statische Gruppen gefiltert. Über diese Gruppen wird iteriert und jeweils dem Zielobjekt hinzugefügt.

Bei einigen Automatisierungen ist es notwendig den Profilpfad eines Benutzers auszulesen und einen eventuellen DFS Pfad in einen physikalischen Pfad aufzulösen.

Hierfür habe ich eine kleine Batch-Datei geschrieben:

@echo off
set samaccountname=%~1
for /f "tokens=* usebackq" %%a in (`AdFind.exe -f "samaccountname=%samaccountname%" profilePath /list`) do (
set profilePath=%%a
)

for /f "delims=<> usebackq tokens=1,2,3,4,5" %%a in (`dfsutil diag viewdfspath %profilepath%`) do (
     if NOT %%e.==. set profilePath=%%e
)

echo %profilePath%

Der Profilpfad wird in Zeile 3 mit Hilfe von adfind anhand des Benutzernamens ermittelt, per for ausgewertet und an eine Umgebungsvariable übergeben.
Diese wird in Zeile 7 an dfsutil übergeben, dass mit dem Befehl diag den physikalischen Pfad anzeigt (ermittelt mit dem aktuellen Standort). Die Ausgabe wird erneut mittels for ausgewertet, wobei die Zeilen an den Größer- und Kleinerzeichen getrennt werden. An fünfter Stelle steht dabei der physikalische Pfad. Handelt es sich bei dem Profilpfad um keinen DFS basierten, dann ist die fünfte Stelle leer und wird daher nicht an die Variable übergeben.

In diesem Blog Post werde ich eine Funktion vorstellen, die anhand eines Abteilungsnamens eine Hierarchie von Organisationseinheiten in Enteo erstellt.

Nehmen wir an, dass die Abteilungen nach einem klaren Muster benannt sind. Jede Hierarchie wird durch einen Buchstaben dargestellt. Eine Abteilung ABC steht somit an dritter Stelle in der Hierarchie. Über ihr steht die Abteilung AB und darüber A.

Diese Hierarchie soll beim Provisionieren eines Computers nachgebildet werden. Der neu zu installierende PC aus der Abteilung ABC wird daher in die OU A\AB\ABC abgelegt werden.

Dies ermöglicht einen abteilungsweisen Rollout.

Die hier vorgestellte Funktion muss daher folgendes leisten:

1. Überprüfen ob die OU schon existiert
2. Falls nicht, den übergebenen Abteilungsnamen zeichenweise zerlegen und bei jeder übergeordneten Abteilung ebenfalls überprüfen, ob diese bereits existiert
3. Die neue OU unter der übergeordneten Abteilung anlegen
4. Die Abteilungs-OU wieder zurückgeben.

Im Rahmen eines aktuellen Projektes darf ich mich ein bisschen mit Enteo beschäftigen. Im Kern basiert Enteo V6 auf WebServices. Das ist leider auch die einzige Schnittstelle, die meines Wissens vom Hersteller für Automatisierungen angeboten wird.

Gerade in einem größeren Rollout Projekt ist Automatisierung überlebenswichtig (bzw. sinnvoll, damit man sich nicht zu sehr bei Drag&Drop langweilt). Zum Glück  hat NWC Services diese Lücke erkannt und als Wrapper um die WebServices ein Powershell Modul erstellt.

Meine Testerfahrungen mit diesem Tool werde ich in diesem Blogeintrag und wahrscheinlich in ein paar weiteren anhand von Beispielen beschreiben.

Vor einigen Tagen hat Microsoft den System Center Updates Publisher (SCUP) in der Version 2011 veröffentlicht.  Er beinhaltet einige interessante Neuerungen:

• Automatic Updates mit SCCM: zuerst wird ein Update nur als metadata veröffentlicht ohne das eigentliche Update herunterzuladen. Bei einer späteren Synchronisation ließt der SCUP aus dem SCCM (System Center Configuration Manager 2007 oder höher) aus, ob Clients dieses update benötigen. Ist dies der Fall, dann lädt er das komplette Update herunter und stellt es in den WSUS zur Verteilung bereit
• Software update Cleanup Wizard: Ermöglicht es nicht mehr benötigte Updates zu bereinigen, indem sie auf expired gesetzt werden
• …

Herunterzuladen ist das Tool unter http://www.microsoft.com/downloads/en/details.aspx?FamilyID=083f45ca-1ede-4f7a-be74-77854c3a9b01.