Eine WinPE auf dem USB-Stick oder als CD/DVD ist außerordentlich praktisch. Man kann damit ein defektes Windows reparieren, seine Daten aus einem kaputten Rechner „rausholen“, ein System aus einem WIM-Image installieren, Images erzeugen und und und…

Zum Erzeugen einer solchen WinPE benötigt man entweder das Windows AIK (Automated Installation Kit) oder eben das ADK. In einer kurzen Anleitung möchte ich erklären, wie hier nun vorzugehen ist:

1.) Windows ADK herunterladen und installieren

Siehe hier: http://www.microsoft.com/de-de/download/details.aspx?id=30652

Bei der Installation reicht es, die „Windows Preinstallation Environment“ auszuwählen, der Rest ist hierzu nicht notwendig.

2.) Es gibt jetzt im Startmenü beim ADK eine „Umgebung für Bereitstellungs- und Imageerstellungstools“. Diese muss (evtl. als Administrator) gestartet werden

3.) In der sich nun öffnenden DOS-Box wird nun das Grundgerüst der WinPE erzeugt. Dazu verwendet man den Befehl:

copype.cmd [x86 | amd64] C:\WinPE

Der erste Parameter gibt an, ob die Umgebung für 32- oder 64-Bit gebaut wird. Mit einer 32-Bit-Variante ist man natürlich deutlich flexibler. Der zweite Parameter gibt an, wo die WinPE erzeugt werden soll, es habdelt sich hier um einen Pfad, der noch nicht existieren darf!

Nach dem Ausführen des Kommandos (welches einige Dateien kopiert) landet man im als Ziel angegebenen Ordner. Unter „media“ befindet sich nun das, was später Bestandteil der WinPE sein wird. Hier kann man weitere Tools hinzufügen, z.B. „imagex.exe“ (einfach mit in den media-Ordner kopieren):

copy "C:\Program Files (x86)\Windows Kits\8.0\Assessment and Deployment Kit\Deployment Tools\x86\DISM\imagex.exe" C:\WinPE\media\

4.) WinPE mit deutschem Tastaturlayout

Das „original“ WinPE ist in Englisch mit englischem Tastaturlayout – das kann stören. Mit ein wenig Arbeit lässt sich das deutsche Layout installieren und aktivieren. Dazu muss die boot.wim, welche sich im meda\sources-Pfad befindet mit dism.exe gemountet und verändert werden.

Das deutsche Language-Pack befindet sich in „C:\Program Files (x86)\Windows Kits\8.0\Assessment and Deployment Kit\Windows Preinstallation Environment\x86\WinPE_OCs\de-de“

dism /Mount-Wim /MountDir:C:\WinPE\mount /wimfile:C:\WinPE\media\sources\boot.wim /index:1
dism /image:C:\WinPE\mount /Add-Package /PackagePath:"C:\Program Files (x86)\Windows Kits\8.0\Assessment and Deployment Kit\Windows Preinstallation Environment\x86\WinPE_OCs\de-de\lp.cab"
dism /image:C:\WinPE\mount /Set-AllIntl:de-DE

Dieser befehl wollte abgeschlossen werden mit:

Das Eingabegebietsschema wurde festgelegt auf: de-DE
Das Systemgebietsschema wurde festgelegt auf: de-DE
Das Benutzergebietsschema wurde festgelegt auf: de-DE
Die Benutzeroberflächensprache wurde festgelegt auf: de-DE
Der Vorgang wurde erfolgreich beendet.

Sonst liegt ein Fehler vor…

Nun noch das Image zurückschreiben:

dism /Unmount-Wim /MountDir:C:\WinPE\mount /commit

5.) Erzeugen der WinPE

Es gibt 2 Möglichkeiten: Einmal in Form einer ISO-Datei (für CD/DVD) oder direkt auf einen USB-Stick (Vorsicht: Dieser wird dabei formatiert, vorhandene Daten gehen verloren!)

Die beiden Befehle lauten:

MakeWinPEMedia /ISO C:\WinPE C:\WinPE\WinPE.iso

-> Für CD-ISO

MakeWinPEMedia /UFD C:\WinPE G:

-> Für USB-Stick/-HDD, G: ist der Buchstabe des USB-Datenträgers, hier kein \ verwenden

Das wäre es schon gewesen – die ISO bzw. der USB-Stick lassen sich jetzt booten…

Update vom 17.12.2017:

Für Windows ADK 10 ändern sich die Pfade und damit auch die Kommandos. Ich habe diese hier nochmal für 64 Bit (amd64) zusammengestellt. Dabei werden auch ein paar nützliche Pakete (u.a. PowerShell) hinzugefügt.

copype.cmd amd64 C:\WinPe
dism /Mount-Wim /MountDir:C:\WinPE\mount /wimfile:C:\WinPE\media\sources\boot.wim /index:1
dism /image:C:\WinPE\mount /Add-Package /PackagePath:"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\de-de\lp.cab"

dism /image:C:\WinPE\mount /Add-Package /PackagePath:"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\WinPE-NetFx.cab"
dism /image:C:\WinPE\mount /Add-Package /PackagePath:"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\de-de\WinPE-NetFx_de-de.cab"
dism /image:C:\WinPE\mount /Add-Package /PackagePath:"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\WinPE-PowerShell.cab"
dism /image:C:\WinPE\mount /Add-Package /PackagePath:"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\de-de\WinPE-PowerShell_de-de.cab"
dism /image:C:\WinPE\mount /Add-Package /PackagePath:"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\WinPE-Scripting.cab"
dism /image:C:\WinPE\mount /Add-Package /PackagePath:"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\de-de\WinPE-Scripting_de-de.cab"

dism /Unmount-Wim /MountDir:C:\WinPE\mount /commit

MakeWinPEMedia /UFD C:\WinPE G:

Nach einem Absturz der SCCM Konsole ist ein Objekt für die Bearbeitung durch den sogenannten SEDO-Lock gesperrt. In meinem Fall war dies heute eine Application (Anwendung):

Neben der früher angesprochenen (und  bis heute nicht supporteten) Variante, den Lock direkt auf der Datenbank zu löschen, gibt es zwei Varianten die unterstützt werden (eigentlich drei – die dritte wäre, 30 Minuten zu warten):

PowerShell:

Die erste Alternative (und auch die erste Wahl ) ist die Verwendung der PowerShell:

Get-CMApplication –Name “NAMEOFTHEAPP” | Unlock-CMObject

Dienst:

Alternativ kann einfach der SMS Executive Dienst neugestartet werden, was die Wartezeit von 30 Minuten abkürzt, aber natürlich auch weitere Folgen für den Betrieb des SCCM hat.

Einige der Neuerungen:

• Support für Windows 10 Anniversary Update
• Windows Information Protection (ehemals EDP)
• Windows Defender Advanced Threat Protection
• Integration für “Windows Store for Business”
• Richtlinien für Windows Hello
• uvm.

Eine komplette Auflistung der Änderungen und Neuerungen ist hier zu finden:

http://technet.microsoft.com/en-US/library/mt752488.aspx

Das Update wird automatisch, aber erst nach und nach verteilt. Wer zu den Ersten gehören möchte, die es bekommen, kann dieses PowerShell-Skript nutzen:

https://gallery.technet.microsoft.com/ConfigMgr-1606-Enable-043a8c50

Viel Spaß damit!

https://youtu.be/-7sCHWDJsaE

<# .Synopsis Returns the Site Code of a SCCM Client as a String .DESCRIPTION Queries a given computer using WMI and returns its site code for System Center Configuration Manager (Tested on 2012 R2 and 1511) .EXAMPLE Get-SMSSiteCode -MachineName PC1 Get's the site code of the Computer named PC1 #>

Function Get-SMSSiteCode
{
    Param(
        # The Computername of the machine that you want to query for it's SCCM Site Code
        [Parameter(Mandatory=$true)]
        [string]$MachineName
    )

    Return (Get-WmiObject -ComputerName $MachineName `
                          -Namespace "root\CCM" `
                          -Class sms_authority `
           ).Name.TrimStart("SMS:")
}

Downloaden könnt ihr das Skript hier!

http://studios.ppedv.de/MedienDokumente.aspx?q=System%20Center

Ihr findet dort Videos zu folgenden Themen:

• Endpoint Protection
• Reporting Services
• Role Based Administration
• Softwareverteilung
• Verwaltung von Linux-Systemen

Viel Spaß beim Ansehen!

Was aber, wenn nicht (nur) der Admin eine Mail erhalten soll, sondern z.B. auch der Vorgesetzte des jeweiligen Benutzers, der die Software angefordert hat? Und was ist mit dem Benutzer selbst? Es wäre doch gut, wenn dieser bei Genehmigung/Ablehnung auch informiert wird?!

Das Ganze lässt sich natürlich wunderbar per PowerShell lösen. Damit nun aber nicht ein Prozess o.ä. permanent laufen muss, wäre es sinnvoll, dieses Skript z.B. nur 1x pro Stunde (über den Taskplaner) automatisch laufen zu lassen. In sofern interessieren in jedem Durchlauf des Skriptes auch nur diejenigen Anforderungen, die

• In der letzten Stunde neu erstellt wurden (“CurrentState” ist 1)
• In der letzten Stunde abgelehnt wurden (“CurrentState” ist 3)
• In der letzten Stunde genehmigt wurden (“CurrentState” ist 4)

Aus dieser Überlegung und der Tatsache, dass sich sowohl der Vorgesetzte als auch die Mailadressen aus dem AD auslesen lassen, resultierte dieses einfache Script (Es ist nicht wirklich “schön” geschrieben, aber zumindest rudimentär kommentiert. Für einen produktiven Einsatz wird man es ohnehin nochmal an die eigenen Bedürfnisse anpassen müssen:

$SiteName = "PS0"
$SiteName = "PS0"
$AdminsMail = "helpdesk@kurs.intern"
$Mailserver = "mail.kurs.intern"
$Absender = "SCCM Application Request Admin"

$MailAnAdmins = $True
$MailAnVorgesetzten = $True

function Send-MyEmail
{

    Param(
        [string]$Sender,
        [string]$Empfaenger,
        [string]$Mailserver,
        [string]$Betreff,
        [string]$Mailtext,
        [Switch]$TestOnly
    )

    try{
        If(-not $TestOnly)
        {
            Send-MailMessage -From $Sender -To $Empfaenger -Subject $Betreff -Body $Mailtext 
                -SmtpServer $Mailserver -ErrorAction Stop
        }
        else
        {
            Write-Host "E-Mail für '$Empfaenger' von '$Sender' über den Mailserver '$MailServer' `n
                        mit dem Betreff '$Betreff' und dem Text:"
            Write-Host "$Mailtext `n"

        }
    }
    catch{
        Write-Debug "Fehler beim Versand der E-Mail über den Mailserver $SmtpServer!"
    }

}

# PS-Modul für AD lasen
Import-Module ActiveDirectory

# PS-Module für SCCM laden
Import-Module "C:\Program Files (x86)\Microsoft Configuration Manager\AdminConsole\bin\ConfigurationManager.psd1"
Set-Location "$($SiteName):\"

# ApprovalRequests auslesen, die sich in der letzten Stunde geändert haben 
# (Script soll stündlich laufen)
$OffeneRequests = Get-CMApprovalRequest | Where {$_.LastModifiedDate -gt (Get-Date).AddHours(-1)}

ForEach($Request in $OffeneRequests)
{
    # Anfordernder Benutzer
    $Benutzer = $Request.User
    $BenutzerLogin = Get-ADUser $($Benutzer.Substring(($Benutzer.IndexOf("\")+1),
                                                       $Benutzer.Length-$Benutzer.IndexOf("\")-1))
    $BenutzerName = ($BenutzerLogin | Get-ADUser).Name
    
    # Anwendung um die es geht
    $Anwendung = $Request.Application

    # Neue Anforderung
    If($Request.CurrentState -eq 1)
    {
        # E-Mail an Admin / Helpdeks senden
        If($MailAnAdmins)
        {
            Send-MyEmail -Sender $Absender -Empfaenger $AdminsMail -Mailserver $Mailserver 
                -Betreff "Neue Softwareanforderung von $BenutzerName" -Mailtext "Blabla..." 
                -TestOnly
        }

        # E-Mail an Vorgesetzten senden
        If($MailAnVorgesetzten)
        {
            # Vorgesetzter des anfordernden Benutzers
            $Vorgesetzter =  ($BenutzerLogin | Get-ADObject -Properties Manager).Manager | Get-ADUser
            $VorgesetzterMail = (Get-ADObject $Vorgesetzter -Properties mail).Mail

            Send-MyEmail -Sender $Absender -Empfaenger $VorgesetzterMail -Mailserver $Mailserver 
                -Betreff "Neue Softwareanforderung von $BenutzerName" -Mailtext "Blabla..." 
                -TestOnly
        }
    }

    # Anforderung wurde durch einen Administrator im SCCM genehmigt
    If($Request.CurrentState -eq 4)
    {
    
        # Mail an den anfordernden User senden
        $BenutzerMail = (Get-ADObject $BenutzerLogin -Properties mail).Mail

        Send-MyEmail -Sender $Absender -Empfaenger $BenutzerMail -Mailserver $Mailserver 
            -Betreff "Ihre Softwareanforderung für $Anwendung wurde genehmigt" -Mailtext "Blabla..." 
            -TestOnly
    }

    # Anforderung wurde durch einen Administrator im SCCM abgelehnt
    If($Request.CurrentState -eq 3)
    {
    
        # Mail an den anfordernden User senden
        $BenutzerMail = (Get-ADObject $BenutzerLogin -Properties mail).Mail

        Send-MyEmail -Sender $Absender -Empfaenger $BenutzerMail -Mailserver $Mailserver 
            -Betreff "Ihre Softwareanforderung für $Anwendung wurde abgelehnt" -Mailtext "Blabla..." 
            -TestOnly
    }
}

In der Ausführung sieht das dann so aus:

Ausführen lässt sich das Skript via Taskplaner dann beispielsweise mit:

powershell.exe -ExecutionPolicy Bypass -file „SCCMMailsFuerApprovalRequests.ps1“

Das Skript lässt sich auch hier herunterladen:

Downloadlink über OneDrive

Hier das Ganze nochmal als direkter Link zu YouTube: https://www.youtube.com/watch?v=CANVBrIEuGE

In Kurzform und wenigen Worten: Man kann die Elemente (bspw. Geräte) markieren (geht mit STRG+A, oder auch mit STRG/SHIFT und Mausklick), mit STRG+C kopieren und dann eben mit STRG+V in Excel einfügen…

https://www.niallbrady.com/2016/01/27/update-1601-now-available-in-system-center-configuration-manager-technical-preview/

Details werde ich in den kommenden Tagen noch ergänzen…

Voraussetzungen:

• Geräte der nicht-vertrauten Domäne (“nvD”) oder der Workgroup (“WG”) können den gewünschten Verwaltungspunkt (“Management Point”, MP) per DNS auflösen
• Verwaltete Geräte in der nvD und/oder der WG können von den Standortsystemservern (“Site Server”) des SCCMs aufgelöst werden (bei nvD zusätzlich der Domänen-Name der nvD)
• Das Konto der Client-Push-Installation hat ausreichend Rechte auf den Zielcomputern
• Bei nvD ist ein Domänen-Account der nvD nötig, der auf den Clients lokale Admin-Rechte hat
• Bei WG-Computern ist ein lokales Admin-Konto nötig, dass auf jedem WG-Computer gleich konfiguriert ist (Name / Passwort)

Um nun den Configuration Manager Client auf einem Gerät in einer Workgroup hinzuzufügen, kann die Push-Installation verwendet werden. Dazu muss a) die Firewall des PCs entsprechend geöffnet werden und b) ein passendes (lokales!) Konto als Push-Installations-Konto hinterlegt werden (Mehrere Konten möglich!):

Außerdem ist es notwendig, ein passendes Netzwerkzugriffskonto (“Network Access Account”) im SCCM zu hinterlegen, denn das Computerkonto des WG-Systems hat ja keine Leserechte auf den Site-Servern der Domäne:

Nun kann der Client mittels Pushinstallation (oder auch händisch!) verteilt werden und Software und co. auf den Arbeitsgruppen-PCs bereitgestellt werden.

Für die Verwaltung von Computern in einer nicht-vertrauten Domäne (nvD) muss zunächst die Gesamtstruktur der nvD bekannt gemacht werden:

Außerdem muss die “Active Directory Systemermittlung” um die externe Domäne (nvD) ergänzt werden:

Damit können denn Geräte der externen Domäne gefunden werden – und später per Push-Installation (siehe oben) mit dem Client betankt und somit verwaltet werden.

Hinweis: Für den Aufbau einer Secondary Site in einer externen Domäne ist eine bidirektionale Vertrauensstellung notwendig! (Two-Way-Trust)