Windows Server 2012 – WSUS Server Cleanup

Die Datenbank des WSUS-Servers sollte regelmäßig von nicht mehr benötigten Updates und Computern bereinigt werden. Diese Funktionen lassen sich beispielsweise aus der Windows Server Update Services MMC Konsole starten. Eine automatische regelmäßige Bereinigung lässt sich aber am besten über die Power Shell einrichten.

Power Shell – Invoke-WsusServerCleanup

Microsoft stellt und ein CMDlet für die WSUS-Server Bereinigung zur Verfügung:

Invoke-WsusServerCleanup [-CleanupObsoleteComputers] [-CleanupObsoleteUpdates] [-CleanupUnneededContentFiles] [-CompressUpdates] [-DeclineExpiredUpdates] [-DeclineSupersededUpdates] [-InformationAction <System.Management.Automation.ActionPreference> {SilentlyContinue | Stop | Continue | Inquire | Ignore | Suspend} ] [-InformationVariable <System.String> ] [-UpdateServer <IUpdateServer> ] [-Confirm] [-WhatIf] [ <CommonParameters>]

Parameter

  • -CleanupObsoleteComputers: Computer bereinigen
  • -CleanupObsoleteUpdates: Nicht mehr benötigte Updates bereinigen
  • -CleanupUnneededContentFiles: Nicht benötigte Dateien bereinigen
  • -CompressUpdates: Nicht mehr benötigte Revisionen der Updates bereinigen
  • -DeclineExpiredUpdates: Abgelaufende Updates bereinigen
  • -DeclineSupersededUpdate: Ersatzte Update bereinigen

WSUS-Server bereinigen

Der folgende Power Shell Befehl kombiniert sämtliche Bereinigungsmöglichkeiten:

Invoke-WsusServerCleanup -CleanupObsoleteUpdates -CleanupUnneededContentFiles -CompressUpdates -DeclineExpiredUpdates -DeclineSupersededUpdates

Windows Server 2012 - WSUS Server Cleaup 1

Regelmäßige WSUS Bereinigung

Mit der Windows Server Aufgabeplanung kann man Aktionen nach einem Zeitplan ausführen lassen. In unserem Fall werden wir ein Power Shell Script wöchentlich automatisch ausführen lassen.

WSUS-Server Cleanup Script

Das eigentlich Script führt letztendlich nur das Power Shell CMDlet Invoke-WsusServerCleanup aus. Parallel dazu wird noch unter C:\WSUS\ eine Log-Datei angelegt und das Ergebnis des Aufrufes per E-Mail an die Administratoren gesendet. Das eigentlich Script wird in diesem Beispiel unter C:\WSUS\WSUS_Cleanup.ps1 gespeichert.

$AktuellesDatum = Get-Date -format ddMMyyyy-HH-mm
$Log = "C:\WSUS-$AktuellesDatum.log"

Invoke-WsusServerCleanup -CleanupObsoleteUpdates -CleanupUnneededContentFiles -CompressUpdates -DeclineExpiredUpdates -DeclineSupersededUpdates | Out-File $Log

$SMTPServer = "192.168.100.16"
$Absender = "m.m@valentin-berlin.local"
$Empfaenger = "m.m@valentin-berlin.local"
$Betreff = "$AktuellesDatum - WSUS Cleanup Script"
$ContentLog = Get-Content $Log | Out-String
Send-MailMessage -SmtpServer $SMTPServer -From $Absender -To $Empfaenger -subject $Betreff -body $ContentLog -Encoding Unicode

Aufgaben hinzufügen

In der Aufgabenplanung kann man nun eine neue einfache Aufhaben anlegen.

Windows Server 2012 - WSUS Server Cleaup 2

Als nächstes muss der Zeitplan und die Aktion definiert werden:

Nun wird der eigentliche Power Shell Script Aufruf konfiguriert. Dabei wird die Power Shell gestartet (ich habe den vollständigen Pfad hinterlegt, weil es sonst manchmal zu Problemen kommen kann) und das eigentliche Script wird per Argument (Parameter) übergeben. Der Pfad zur Power Shell ist übrigens bei allen Versionen gleich.
Power Shell Aufruf:

%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe

Power Shell Arugemente (Parameter):

-noninteractive -command "&{C:\WSUS\WSUS_Cleanup.ps1}"

Windows Server 2012 - WSUS Server Cleaup 6

Status E-Mail

Bei jedem Durchlauf wird eine E-Mail mit dem Status verschickt. Das Ganze kann dann folgerdermaßen aussehen:

Windows Server 2012 - WSUS Server Cleaup 8

Windows Server 2012 – Remote Power Shell Zugriff per Gruppenrichtlinie aktivieren

Der Remote Power Shell Zugriff auf andere Computer / Server hat viele Vorteile. Man kann z.B. von einem Computer aus, alle anderen Computer / Server per Power Shell verwalten.

Remote Power Shell zugriff aktivieren

Der Power Shell Rempte Zugriff, die Windows Remote Verwaltung und die dazugehörigen Firewall-Richtlinien müssen konfiguriert werden.

Dienst Windows-Remoteverwaltung automatisch starten

Damit der Remote Power Shell Zugriff überhaupt funktionierne kann, muss der Dienst „Windows-Remoteverwaltung (WS-Verwaltung)“ automatisch gestartet werden. Dieser kann in der Gruppenrichtlinien Verwaltungskonsole unter „Computerkonfiguration -> Richtlinien -> Windows Einstellungen -> Sicherheitseinstellungen -> Systemdienste“ konfiguriert werden.

Remoteshellzugriff zulasse

In der Gruppenrichtlinien Verwaltungskonsole unter „Computerkonfiguration -> Richtlinien -> Administrative Vorlagen -> Windows-Komponenten -> Windows Remoteshell“ gibt es den Punkt „Remoteshellzugriff zulassen“. Dieser muss aktiviert werden.

Remoteverwaltung über WnRM zulassen

Nun muss in der Gruppenrichtlinien Verwaltungskonsole unter „Computerkonfiguration -> Richtlinien -> Administrative Vorlagen -> Windows-Komponenten -> Windows Remoteverwaltung -> WinRM-Dienst“ der Punkt „Remoteverwaltung über WnRM zulassen“ konfiguriert werden. Hier können einzelne IPV4 oder IPV6 Adressen berechtigt werden. Alternativ kann man mit einem „*“ alle IP-Adressen zulassen.

Hier kann man jetzt z.B. noch HTTP / HTTPS aktivieren oder verschiedene Authentifizierungsmethoden konfigurieren. Dies ist aber keine Voraussetzung.

Windows Firewall

Abschließend muss nur noch die Windows Firewall dahingehend geöffnet werden. Hier gibt es aber schone ine Vorgefertige Richtlinie, dir nur noch aktiviert werden muss. Diese kann in der Gruppenrichtlinien Verwaltungskonsole unter „Computerkonfiguration -> Richtlinien -> Windows Einstellungen -> Sicherheitseinstellungen -> Windows-Firewall mit erweiteter Sicherheit -> Windows-Firewall mit erweiteter Sicherheit“ aktiviert werden. Es muss dafür Ein- und Ausgehende Regeln geben. Die Richtilinie die aktivert werden muss heißt „Windows-Remoteverwaltung“.

Windows 10 – Administrative Templates (Gruppenrichtlinien) aktualisieren (ADMX)

Update vom 24.08.2015: Fehler nach der Installation der Administrativen Templates deaktiveren

Hier habe ich einen Beitrag über mögliche Fehler und deren Korrektur geschrieben: http://chilltimes.de/2015/08/24/windows-10-gruppenrichtlinien-fehlermeldungen-nach-installation/

Update vom 06.08.2015: Offizieller Download verfügbar

Der offizielle Download wurde von Microsoft am 04.08.2015 bereitgestellt: Administrative Templates (.admx) for Windows 10 – Deutsch

 

ADMX-Dateien aus Windows 10 Installation

Um die Windows 10 Clients über Gruppenrichtlinien (Administrative Templates, ADMX) im vollen Umfang konfigurieren zu können, müssen die Policy Definitions auf dem Domain Controllern durch aktuelle Administrative Templates ersetzt werden. Microsoft veröfffentlich wohl irgendwan ein seperates Download Paket. Bis dahin kann man sich aber selber behelfen und die Administrative Templates (ADMX-Dateien), aus einer bestehenden Windows 10 Installation herauskopieren und in die Policy Defintions auf den Comain Controllern kopiert werden.

Administrative Templates aktualisieren

Gruppenrichtlinien aus Windows 10 kopieren

Die neuen ADMX Dateien liegen unter Windows 10 in folgendem Pfad:

C:\Windows\PolicyDefinitions

Windows 10 Gruppentichtlinien 1

Gruppenrichtlinien auf Domain Controller kopieren

Die eben kopierten Gruppenrichtlinien können nun auf den Domain Controller kopiert werden. Die ADMX-Datein müssen in folgendes Verzeichnis eingefügt werden. Dabei müssen die alten Datein durch die neuen Dateien überschrieben werden.

\\domain-cotroller\sysvol\domain\Policies\PolicyDefinitions

Windows 10 GruppentichtlinienFehler in Microsoft-Windows-Geolocation-WLPAdm.admx

Nach der Installation der Administrativen Templates, erscheint beim Aufruf einer Gruppenrichtlinie im Gruppenrichtlinienverwaltungs-Editor ein Fehler. Die Datei Microsoft-Windows-Geolocation-WLPAdm.admx verwendet den gleichen Namespace wie die alte Datei LocationProviderAdm.admx. Also einfach die alte Datei entfernen. (Danke an D. Zunkel)

PS: Diesen Fehler habe ich z.B. in der Windows-Feedback App gemeldet 😉

Gruppenrichtlinienverwaltungs-Editor

Im Gruppenrichtlinienverwaltungs-Editor können die neuen ADMX-Templates nun eingesehen werden. Diese befinden sich unter „Adminsitrative-Vorlagen“. Beim ersten Auruf dauert es ein paar Minuten, bis diese geladen wurden. Nun stehen weitere Konfigurationsmöglichkeiten zur Verfügung, die Windows 10 und z.B. auch Microsoft Edge einschließen.

Active Directory – Adressliste generieren

Mit der Powershell kann man sehr einfach, auf Grundlage des Active Directorys, eine Adressliste des Unternehmens generieren. Im folgendem Beispiel werden die Spalten Name, Abteilung, Telefonnummer, Mobiltelefonnummer und E-Mail Adresse ausgelesen, die Mitarbeiter nach Namen sortiert und anschließend als CSV exportiert.

Powershell Beispiel

get-aduser -SearchBase 'ou=Mitarbeiter,Dc=domain,DC=local' -filter 'objectClass -eq "user"' -Properties * | Sort-Object surname | Select-Object name, department, officephone, mobilephone, emailaddress | Export-Csv adressliste.csv

Ergebnis

Active Directory - Adressliste export

Office Web Apps 2013 – Installation

Der Office Web Apps Server 2013 wird gleich von mehreren Microsoft Produkten benötigt:

  • Lync Server 2013: Zum rendern der PowerPoint Präsentationen in allen Clients
  • Exchange Server 2013: Stellt alle kompatiblen Dateiformate in Office Web App da (Word, Excel, PowerPoint, OneNote, PDF)
  • Sharepoint Server 2013: Stellt die Schnellansicht bei Dokumenten bereit

Das Anzeigen von Dokumenten sollte kostenlos sein, das Bearbeiten benötigt allerdings eine kostenpflichtige Lizenz.

Voraussetzungen

Windows Rollen und Features

Add-WindowsFeature  Web-Server, Web-Mgmt-Tools, Web-Mgmt-Console, Web-WebServer, Web-Common-Http, Web-Default-Doc, Web-Static-Content, Web-Performance, Web-Stat-Compression, Web-Dyn-Compression, Web-Security, Web-Filtering, Web-Windows-Auth, Web-App-Dev, Web-Net-Ext45, Web-Asp-Net45, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Includes, InkandHandwritingServices

Office Web Apps 2013 – Installation

Die generelle Installation ist sehr einfach. Einfach nur durchklicken:

Office Web Apps 2013 – Konfiguration

Auch wenn nur ein Server vorgesehen ist, muss immer eine Office Web Apps Farm erstellt werden:

New-OfficeWebAppsFarm -InternalURL "http://wac.domain.local" -ExternalURL "http://wac.domain.de" -AllowHttp -EditingEnabled:$False -SSLOffload

Office Web Apps 2013 – Optionale Einstellungen

Man kann den Office Web Apps Server 2013 so einstellen, dass dieser beim Aufruf der URL ein Formular anzeigt, mit dem man jedes Office Dokument im Browser darstellen kann:

Set-OfficeWebAppsFarm -OpenFromUrlEnabled -OpenFromUncEnabled -OpenFromUrlThrottlingEnabled

Hinweise zur Installation der Updates

Direkt nach der Installation gibt es mindestens ein Update das direkt angewendet werden kann. Nach der Installation kann es vorkommen, dass der Office Web Apps Server 2013 nicht mehr funktioniert und sich auch nicht reparieren lässt. Hier hilft das Löschen der Office Web Apps 2013 Farm und das erneute Anlegen. Ist ja nur ein Powershell-Befehl, den man dokumentieren sollte.

Exchange Server 2013 – Konfiguration

Nun kann der neue Office Web Apps 2013 Server im Exchange Server aktiviert werden:

Set-OrganizationConfig -WACDiscoveryEndpoint https://wac.domain.de/hosting/discovery
Get-OWAVirtualDirectory | Set-OWAVirtualDirectory -WacViewingOnPublicComputersEnabled $true -WacViewingOnPrivateComputersEnabled $true

Sharepoint 2013 – Konfiguration

Auch die Sharepoint 2013 Konfiguration für Office Web Apps ist sehr einfach. Es muss nur der Server bekannt gegeben und ggf. die Zone auf HTTPS definiert werden.

New-SPWOPIBinding -ServerName wac.domain.local
Set-SPWOPIZone –zone “external-https”

Lync Server 2013 – Konfiguration

Die Konfiguration im Lync Server 2013 ist noch einfacher: Hier muss man nur den Topologiebuilder ausführen und eine neue Outlook Web Apps Ressource erstellen, mit den eben erstellen Parametern.

Exchange Server 2013 – Malware Scanner & Anti Spam Agents #2

Im zweiten Teil der Exchange 2013 Malware & Anti-Spam Agents Konfiguration werden die einzelnen Anti-Spam Agents konfiguriert. (Zum ersten Teil)

Anti-Spam Agents – IP Block List

Mit diesem Agent lassen sich IP-Adressen blockieren. Es können manuell einzelne IP-Adressen hinterlegt werden oder auch ganze dynamisch generierten Listen von kostenlosen Anbietern wie „spamcop.net“.

IP Block List Provider

IP Block List Provider sind kostenlose Anbieter solcher IP-Blacklists. Beim Eintreffen einer E-Mail wird die IP-Adresse des Absenders an den jeweiligen Anbieter geschickt und wenn dieser keine Rückantwort liefert, steht die IP nicht auf seiner Liste.

In diesem Beispiel wird der IP Block List Provider „zen.spamhaus.org“ hinzugefügt:

Add-IPBlockListProvider -name zen.spamhaus.org -lookupdomain zen.spamhaus.org

Diese IP Block List Provider haben sich in meiner Exchange Server 2013 Umgebung bewährt und filtern schon sehr viele IP Adressen und haben dabei ein sehr gutes false/positive Verhältnis.

Add-IPBlockListProvider -name bl.spamcop.net -lookupdomain bl.spamcop.net
Add-IPBlockListProvider -name zen.spamhaus.org -lookupdomain zen.spamhaus.org
Add-IPBlockListProvider -name dnsbl.sorbs.net -lookupdomain dnsbl.sorbs.net
Add-IPBlockListProvider -name ix.dnsbl.manitu.net -lookupdomain ix.dnsbl.manitu.net
Add-IPBlockListProvider -name cbl.abuseat.org -lookupdomain cbl.abuseat.org
Add-IPBlockListProvider -name spam.dnsbl.sorbs.net -lookupdomain spam.dnsbl.sorbs.net
Add-IPBlockListProvider -name b.barracudacentral.org -lookupdomain b.barracudacentral.org
Add-IPBlockListProvider -name sbl-xbl.spamhaus.org -lookupdomain sbl-xbl.spamhaus.org
Add-IPBlockListProvider -name psbl.surriel.com -lookupdomain psbl.surriel.com

Anti-Spam Agents – Content Filter

Der Content Filter Agents analysiert die E-Mail auf Inhalt und gibt dieser einen SCL-Wert. Nun muss nur noch konfiguriert werden, was bei welchem SCL passieren soll. Es gibt hier 3 Möglichkeiten:

  • E-Mail in Quarantäne verschieben
  • E-Mail ablehnen und Nachricht an Absender
  • E-Mail ohne Nachricht an Absender löschen

Content Filter – Quarantäne-Postfach

Für den Content Filter kann ein Quarantäne-Postfach konfiguriert werden. In dieses werden dann E-Mails mit einem definierbaren SCL-Wert verschoben. In diesem Quarantäne-Postfach können dann ggf. gefilterte E-Mail entlassen oder gelöscht werden. Es empfiehlt sich auf jeden Fall ein gesondertes Postfach für diesem Zweck anzulegen, wann dann bei Bedarf eingebunden werden kann.

In diesem Beispiel werden alle E-Mails mit einem SCL-Wert größer 6 in das Quarantäne-Postfach „spam@test.local“ verschoben:

Set-ContentFilterConfig -SCLRejectEnabled $true -SCLQuarantineThreshold 6 -SCLDeleteEnabled $false -SCLRejectEnabled $false -QuarantineMailbox spam@test.local

Anti-Spam Agents – Sender ID

Der Sender ID Filter überprüft den SPF-Record der jeweiligen Domain und reagiert dann mit einer der folgenden Aktionen:

  • E-Mail mit Status kennzeichnen
  • E-Mail ablehnen und Nachricht an Absender
  • E-Mail ohne Nachricht an Absender löschen

E-Mails bei denen der SPF-Record nicht korrekt ist, sollten bei externen Servern abgelehnt werden. Der Absender bekommt dann eine Unzustellbarkeitsmeldung und kann ggf. reagieren. Man kann die E-Mail natürlich auch ohne Meldung sofort löschen, dann bekommt der Absender aber keine Benachrichtigung.

Set-SenderIdConfig -Enabled $true -ExternalMailEnabled $true -SpoofedDomainAction Reject -TempErrorAction StampStatus

Sender ID Filter – Ausnahme

Ich habe oft erlebt, dass grade kleiner Firmen den SPF-Record falsch setzen und damit E-Mail abgelehnt werden. Für solche Fälle kann die jeweilige Absender-Domain ausgeschlossen werden:

Set-SenderIdConfig -BypassedSenderDomains test.de

Exchange Server 2013 – Installation

Hier wird eine Installation mit einer neuen Exchange Organisation beschrieben. Wenn der neue Exchange Server in eine Umgebung mit bereits installierten Exchange Server 2010 installiert werden soll, müssen diese erstmal auf Service Pack 3 geupdatet werden. Außerdem sollte bei der Installation von Exchange Server 2013 gleich die Version mit Service Pack 1 installiert werden und das Rollup 1 gemacht werden. Da sonst eine Koexistenz beider Exchange Versionen nicht möglich ist.

Vorraussetzungen

Bevor das Exchange Server 2013 Setup ausgeführt werden kann, müssen auf einem Windows Server 2012, folgende Vorraussetzungen erfüllt werden:

Office 2010 Filter Pack x64 & Service Pack 1

Das Office 2010 Filter pack ermöglicht die Volltext-Indizierung von Office Dateien wie Word, Excel, usw. Wenn beispielsweise ein Word Dokument als Anhanh in einer E-Mail existiert, wird dieses Dokument indeziert und kann dann in der Suche gefunden werden.

Unified Communications Managed API 4.0 Runtime

Die Unified Communications Managed API 4.0 Runtime fügt Funktionen für die Microsoft Enhanced Presence-Informationen, Chatnachrichten, Telefon- und Videoanrufe sowie Audio- und Videokonferenzen hinzu. Somit wird es beispielsweise möglich, Lync Funktionen in der Outlook Web App einzubinden.

Exchange Server 2013 – Active Directory vorbereiten

Active Directory Schema erweitern

Es werden die Exchange Server LDIF-Dateien importiert und damit das Schema um Exchange Server 2013 Attribute erweitert. Außerdem wird die ms-Exch-Schema-Verision-Pt auf 15137 festgelegt.

setup /PrepareSchema /IAcceptExchangeServerLicenseTerms

Active Directory vorbereiten

Wenn noch keine Exchange Organisation vorhanden ist, muss der Parameter /OrganizationName angegeben werden. Es wird ein Container angelegt (CN=,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=) und einige Objekte erstellt. Außerdem werden Rollen und Sicherheitsgruppen angelegt. Was genau passiert kann hier nachgelesen werden: http://technet.microsoft.com/de-de/library/bb125224%28v=exchg.150%29.aspx

setup /PrepareAD /OrganizationName ExchangeOrganisation /IAcceptExchangeServerLicenseTerms

Domain vorbereiten

Es wird ein neuer Container erstellt (Microsoft Exchange-Systemobjekte). Außerdem werden Berechtigungen gesetzt.

setup /PrepareAllDomains /IAcceptExchangeServerLicenseTerms

Exchange Server 2013 – Installation

Nachdem alle Vorraussetzungen erfüllt sind und das Active Directory aktualisiert wurde, kann die Installation beginnen. Während der Installation ist nicht wirklich viel zu konfigurieren. Entscheidend ist eigentlich nur die Konfiguration, über die zu installierenden Rollen.

Gruppenrichtlinien – ADMX Templates

Mit Windows Server 2008 R2 wurden ADMX-Templates eingeführt. Diese Templates erweitern die Gruppenrichtlinien um neue Einstellungen, Produkte oder Vesionen.

Offizielle Microsoft Templates

Gruppenrichtlinien – Central Store

Der Gruppenrichtlinien Central Story liegt auf den Domain Controllern im Vewrzeichnis „\FQDN\SYSVOL\FQDN\Policies“. Nach der Installation von Windows Server 2012 sind hier noch keine ADMX-Templates vorhanden. Diese müssen erstmal erstellt werden. Diese können entweder durch die oben aufgeführten ADMX-Templates installiert werden oder aus der jeweiligen Installation kompiert werden.

Die ADMX-Templates von Windows Server 2012/Windows 8 liegen beispielsweise im ordner „C:\Windows\PPolicyDefinitions\“ und können von hier aus in den Central Store kopiert werden.

Gruppenrichtlinien im Central Store aktualisieren

Neue ADMX-Template sollten immer auf dem Basisdomänencontroller installiert werden. Dieser syncronisiert diese dann an alle anderen Domänencontroller. Im Gruppenrichtlinien Central Store liegen alle GPO´s. In dieses Verzeichnis müssen die neuen Templates auch kopiert werden.

\FQDN\SYSVOL\FQDN\Policies

Gruppenrichtlinien – Client

Die Domänen Computer aktualisieren die Gruppenrichtlinien alle 90 Minuten. Dies kann auch manuell durchgeführt werden.

Gruppenrichtlinien – Client aktualisieren

Mit folgendem Befehl kann man ein Update der Gruppenrichtlinien auf dem Client erzwingen.

gpupdate /force

Sharepoint Foundation 2013 – Installation

Beim Ausführen der Sharepoint Foundation 2013 muss zuerst die Installation der Vorraussetzungen durchgeführt werden. Erst dann kann die Installation erfolgen.

1

Vorraussetzungen:

Die Installation der Vorraussetzungen wird bei bestehender Internet-Verbindung automatisch durchgeführt. Bei mir hat dies auf einem Windows Server 2012 nicht funktioniert. Alle Komponenten lassen sich aber auch manuell Installieren. Eine Besonderheit ist der „Windows Server AppFabric Manager“. Dieser muss mit einem speziellen Parameter ausgeführt werden: /i /gac

2

Installations Arten

Standalone: Sharepoint Foundation 2013 bringt einen SQL Server 2008 R2 Express mit. Dieser kann während der Installation automatisch mit installiert werden. Die hat allerdings einige Nachteile, wie z.B. ein 10 GB Datenbank-Limit.

Complete: Alternativ kann man auch manuell einen SQL Server aufsetzen und diesen bei der Installation angeben.

6installation_med

Konfigurationsassistent für SharePoint Produkte

Nach der Installation muss der Konfigurationsassistent ausgeführt werden. Hier wird in 10 Schritten die Grundkonfiguration von Sharepoint erstellt.

SharePoint 2013 Zentraladministratrion

Nun kann die Zentraladministration ausgeführt werden. Das Ganze sieht dann wie folgt aus:

10

PowerShell – WebAccess Installation/Konfiguration

Windows Server 2012 bringt ein neues Feature mit sich: PowerShell Web Access. Damit kann man in so gut wie jedem Browser, eine PowerShell Session öffnen. Das tolle an diesem Feature ist, dass man beim Login jeden Computer/Server zur Anmeldung auswählen kann. Somit muss nicht nicht extra eine Remote Session aufbauen.

PowerShell WebAccess Instalieren

Um die Funktion benutzen zu können, muss ein Windows Feature installiert werden.

PowerShell WebAccess Instalieren – Windows Feature

Mit dem folgendem Befehl, wird das Windows Feature installiert:

Install-WindowsFeature -Name WindowsPowerShellWebAccess -ComputerName localhost -IncludeManagementTools -Restart

PowerShell WebAccess Instalieren – Einrichtung des Gateway

Sollte bereits ein gültiges SSL Zertifikat dem IIS zugeordnet sein, kann folgender Befehl zur Konfiguration ausgeführt werden:

Install-PswaWebApplication

Sollte noch kein SSL Zertifikat dem IIS zugeordnet sein, kann folgender Befehl zur Konfiguration ausgeführt werden und es wird ein selbstsigniertes Zertifikat erstellt:

Install-PswaWebApplication -UseTestCertificate

PowerShell WebAccess Instalieren – Autorisierungsregel

Dem Usernamen * und dem Computernamen * wird der Zugriff erlaubt. Man kann natürlich auch nur einem bestimmten Benutzer/Computer den Zugriff erlauben.

Add-PswaAuthorizationRule -UserName * -ComputerName * -ConfigurationName microsoft.powershell

Beispiel

Das ganze sieht dann so aus: