Enteo: Statische Computer-Gruppenzuordnung klonen

configurationWird 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.

Um das Powershellskript einfach aufzurufen hier noch eine Batch-Datei:

@echo off
set /p source=Bitte Quellrechnernamen eingeben:
set /P target=Bitte Zielrechnernamen eingeben:
powershell "%~dp0clonecomputer.ps1" -sourcename "%source%" -targetname "%target%"
pause

 

Posted in Deutsch, Tools | Tagged , | Leave a comment

SCCM: Verteilung von Visio und Project 2010

Person-group-addDie Verteilung von Visio und Project 2010 ist ähnlich wie Office 2010 sehr einfach. Im Gegensatz zu Office 2010, bei dem man eine MSP Datei erstellt, ändert man bei Visio und Project die config.xml Datei entsprechend ab. Diese Datei liegt im Visio.ww bzw PrjStd.ww Verzeichnis.

Eine Beispiel-Config kann so aus sehen: (innerhalb des umgebenen <Configuration> Bereichs)

<Display Level="none" CompletionNotice="no" SuppressModal="no" AcceptEula="yes" />
<Logging Type="Verbose" Path="%temp%" Template="VisioProject_Setup(*).txt" />
<USERNAME Value="Benutzername" />
<COMPANYNAME Value="Firma" />
<PIDKEY Value="abcdefg" />
<INSTALLLOCATION Value="%programfiles%\Microsoft Office" />

Continue reading

Posted in Configuration Manager, Deutsch, System Center | Tagged , , , | 1 Comment

SCOM: Betrachtung des Heartbeats

pipeEin Heartbeat ist eine wesentliche Komponente innerhalb eines Monitoringsystems. Dabei schickt der Client regelmäßig eine Alive Meldung an den Server. Bleibt diese eine gewisse Zeit aus, dann wird der Client als defekt gemeldet.

Auch der System Center Operation Manager (SCOM) hat ein solches Feature. Die Einstellungen werden primär global im Administrations –> Settings Bereich gemacht.

Dort gibt es zwei primäre Einstellungen:

1. Heartbeat Time: die Zeit, die zwischen zwei Heartbeats vertreichen darf, ohne dass dieser als vermisst angesehen wird.

2. Server –> Heartbeat Server Count: Die Anzahl der Heartbeats, die verloren gehen können, bevor ein Client als vermisst angesehen wird.

Standardmäßig steht die Heartbeat Time auf 180 Sekunden und der Counter auf drei. Somit darf ein Client bis zu neun Minuten weg sein, bevor dieser als fehlerhaft markiert wird.

Dabei hat der SCOM ein weiteres Feature: Sobald der Heartbeat ausgeblieben, ist Ping der Server den Client automatisch an, um herauszufinden ob eventuell nur der SCOM Dienst steht oder das komplette System weg ist. An dieses Ergebnis kann natürlich SCOM-Typisch ein Recovery Task wie z.B. ein Neustart des Diensts angehängt werden. Der Ping-Monitor hängt übrigens nicht am eigentlichen Client-Objekt, sondern an einem getrennten Objekt, der unterhalb des SCOM-Servers hängt (Client-Watcher).

Posted in Deutsch, Operations Manager, System Center | Tagged | Leave a comment

Doppelte Rechnereinträge in SCCM 2007 R3

play_buttonBei einem Kunden haben wir momentan das Problem, dass es für jeden per OSD neu installierten Rechner zwei Einträge gibt. Einer mit einem aktiven Client und ein zweiter ohne Client aber mit den Active Directory Gruppen. Da die Verteilung von individueller Zusatzsoftware per AD Gruppen erfolgt ist dies ein Problem, da zwar die Collectionzuordnung erfolgt, als Ziel aber der falsche Client verwendet wird. Aktiv ist das neue Delta-Discovery (5min) von R3 und auch eine relativ kurzes Full-Discovery.

Die SCCM Produkt Gruppe hat zu diesem Problem bereits einen Workaround beschrieben, der anhand der Anleitung auch sehr gut umzusetzen war:

http://blogs.technet.com/b/configmgrteam/archive/2011/08/17/known-issue-and-workaround-duplicate-records-when-you-use-unknown-computer-support-with-active-directory-delta-discovery.aspx

Posted in Configuration Manager, Deutsch, System Center | Tagged | Leave a comment

SCCM: 64bit Variante unabhängig vom Kontext ausführen

refreshSCCM 2007 setzt (noch) 32bit Agenten ein. Daher wird auch ein Programm zuerst einmal im 32bit Kontext ausgeführt und bekommt daher über die Redirects primär Zugriff auf das syswow64 Verzeichnis. Startet man ein regedit, so wird die 32bit Variante gestartet. Es gibt Situationen, in denen man auf jeden Fall die OS native Variante starten möchte, d.h. auf einem x64 die 64bittige und analog auf einem x86 die 32bit. Dazu kann man in einer Batchdatei überprüfen ob bestimmte Kriterien erfüllt sind, oder man verwendet direkt einen (auch mir vor kurzem Smile) eher unbekannten Alias: sysnative.

So kann man einen Aufruf von %windir%\system32\regedit.exe ersetzen durch %windir%\sysnative\regedit.exe. Im WOW64 Kontext wird dieser Alias erkannt und durch den Verweis auf die 64bit Variante ersetzt.

Details dazu sind auch in der MSDN von Microsoft zu finden: http://msdn.microsoft.com/en-us/library/aa384187%28v=vs.85%29.aspx

Posted in Configuration Manager, Deutsch, System Center | Tagged | Leave a comment