Zugriff auf Shared Folder von Virtualbox über Powershell

Stand auch schon jemand vor dem Problem über die Powershell auf einen Ordner zuzugreifen, der vom Host aus mit der VM geteilt wird? Dieser hat bei mir den Laufwerksbuchstaben E: und ich bekam nur den Fehler „Set-Location: Das Laufwerk wurde nicht gefunden…..“

Das Laufwerk war aber im Explorer da und auch über die CMD erreichbar. Das Problem habe laut Google nicht nur ich – was also tun?

Über \\vboxsvr\SHARENAME ist der geteilte Ordner auch erreichbar. Daher besteht die Möglichkeit, einen Link zum „Networkshare“ anzulegen. Hierzu wird die CMD geöffnet und folgender Befehl eingetippt:

mklink /d ORDNERNAME \\vboxsvr\SHARENAME

Den Ordner habe ich auf dem Desktop in meinem Userverzeichnis platziert und habe daher in der Powershell dorthin navigiert:

cd C:\Users\USERNAME\Desktop\SHARENAME

Mit dem Befehl „dir“ kann man sich dann den Share-Inhalt anzeigen.

Leider geht das Mounten als Laufwerk somit nicht, aber der Zugriff auf die Dateien und das Arbeiten mit diesen innerhalb der Powershell ist somit möglich.

Powershell erneut mit anderem Benutzer öffnen

Wenn eine Powershell-Session aus Versehen mit dem falschen Benutzer initiiert wird, kann dies mitunter ärgerlich sein – man lümmelt halb unter dem Schreibtisch und hat die Maus nur relativ umständlich parat. Kommt das dem ein oder anderen bekannt vor?

Hier gibt es nun die Möglichkeit, die Powershell aus der Powershell heraus zu öffnen. Hierzu wird Start-Process auf der Powershell aufgerufen und entsprechend parameterisiert:

Start-Process powershell.exe -Credential „DOMAIN\USER“

Hierdurch wird eine neue Powershell geöffnet, die im Kontext des entsprechenden (Admin-)User geöffnet ist. Der Einfachheit halber ist das Fenster unmittelbar fokussiert.

Eine andere Möglichkeit wäre es, ein Script (.ps1) zum Beispiel mit der Powershell ISE zu erstellen. Dies soll dann direkt im Admin-Kontext ausgeführt werden. Wichtig ist hierbei, dass die Execution-Policy auf Unrestricted gesetzt wird, da die Powershell das Script sonst blockt.

Start-Process powershell.exe -Credential „DOMAIN\USER“ -NoNewWindow -ArgumentList „Start-Process powershell.exe -Verb runAs“

 

wttr.in – Wetterbericht in ASCII

Stolzer OS X-Benutzer und Interesse an Spielereien? Wetterbericht mal anders im Terminal (auch *NIX)? Igor Chubin hat hier eine tolle Spielerei bereitgestellt.

Grundsätzlich muss man nur folgenden Befehl eingeben:

curl http://wttr.in/AUFENTHALTSORT

Das http ist optional und kann bei Bedarf auch weggelassen werden.

Für „Calw“ im schönen Schwarzwald sieht dies so aus:

wttr.in/calw

Sofern keine Stadt angegeben ist, nimmt wttr.in automatisch einen Punkt in der Nähe. Die Zielgenauigkeit lässt aber etwas zu wünschen übrig, da Leinfelden-Echterdingen ein wenig von Calw differiert. :)

wttr.in nochoice

Wer den Wetterbericht in ASCII auch für Windows sehen will, kann sich nun auch freuen: Igor hat bekannt gegeben, dass dies auch mit der Powershell möglich ist.

wttr.in powershell

Allerdings scheine ich hier mit der Codierung einige Probleme zu haben. Diese möchte ich aber nicht weiter vertiefen, da wttr.in grundsätzlich funktioniert und ich es auf der Powershell – wenn überhaupt – wohl nie nutzen werde.

In diesem Sinne: Happy ASCII’ing.

 

Update:

Gerade bekam ich eine Mail von Igor Chubin, in der er mein Problemchen mit dem Abruf von wttr.in in Powershell angesprochen hat. Hier muss ich doch ein wenig um Absolution bitten, da ich dem Thema mit der Powershell wohl zu wenig Gewicht beigemessen habe. In der Mail wurde ich auf Twitter verwiesen, dort ist wiederum ein Link zu Github hinterlegt, der ANSI-Sequenzen in der Powershell aktiviert. Nachdem dies fehlerlos durchgelaufen ist, kann ich Erfolg vermelden, die Abfrage mit der Powershell klappt nun auch schön, schnell und fehlerlos. Danke für die kurze Rückmeldung Igor. :)wttr.in powershell working

 

Erstellen einer neuen Windows-Domäne

Zentrale Funktion einer großen IT-Umgebung ist in der Regel ein sogenanntes Directory. Hier werden neben Containern (z.B. Gruppen) auch einzelne Objekte wie zum Beispiel Benutzer, Computer-Konten und so weiter gespeichert und in Relation zueinander gebracht. Hierdurch können komplexe Rechtestrukturen erstellt werden, um Dateien und Dienste an spezielle Teilnehmer des Netzwerkes zu liefern oder diese zu verwehren. Ferner ist das Directory auch Grundlage für viele darauf aufbauende Dienste wie zum Beispiel Microsoft Exchange,…

Um ein Active Directory aufzubauen, muss im Server-Manager erst die entsprechende Rolle installiert werden:

Rollen und Features hinzufügen

Im Server-Manager wird unter Verwalten der Punkt „Rollen und Features hinzufügen“ ausgewählt.

Assistent der Rollen und Features

Im nächsten Moment gibt der Assistent eine kleine Erklärung/Auflistung.

RuF basierte Installation oder Remote Desktop

Im nächsten Fenster muss die Art der Installation bestimmt werden. Da es nicht um Remote Desktop-Dienste geht, kann die Einstellung so beibehalten werden. -> Weiter

Serverauswahl

Der Server, auf dem die Installation stattfinden soll, muss ausgewählt werden. Da es bisher nur einen Server in der Umgebung gibt, ist die Auswahl entsprechend leicht. Der Name ist optional und PDC lediglich aus nostalgischen Gründen gewählt.

Rollenauswahl

Im folgenden Fenster wird ADDS ausgewählt (Active Directory-Domänendienste).

Autofeatures

Windows erkennt automatisch die benötigten Features. Diese können nicht abgewählt werden, somit: Weiter mit Features hinzufügen.

Features Auswahl

Sollten noch weitere Features gewünscht sein, können diese angehakt werden. Hier wird alles vorerst so belassen, wie benötigt. -> Weiter

DC overview

Zum Abschluss wird noch eine Zusammenfassung geliefert, in der ADDS nochmals thematisiert wird und auf grundsätzliche Praktiken (z.B. 2 DC’s für Replikation bei Serverausfall) eingegangen wird. -> Weiter

Bestätigung ADDS

Zum Schluss wird die Bestätigung nochmals aufsummiert. -> Installieren

Installation abwarten

Die Installation startet. Das Fenster kann währendessen offen gelassen oder geschlossen werden.

After Installation Server-Manager

Nach der Installation ist im Server-Manager oben am Rand ein kleines Ausrufezeichen an der Informationsfahne hinterlegt. -> Klick

Server zu einem Domänencontroller heraufstufen

Jetzt muss mit der Konfiguration fortgefahren werden. Hierzu wird auf „Server zu einem Domänencontroller heraufstufen“ geklickt.

valhalla.local

Im nächsten Schritt wird zuerst eine neue Gesamtstruktur erstellt. Diese wird am besten eindeutig benannt. Im Beispiel heißt die Domäne „valhalla.local“. Die Endung .local veranschaulicht hier die Trennung der lokalen Infrastruktur vom Internet. -> Weiter

Domänencontrolleroptionen

In den Domänencontrolleroptionen wird eingestellt, auf welchen Ebenen die Domäne funktioniert. Hier werden im Beispiel die Standardwerte belassen, für detaillierte Beschreibungen der Neuerungen kann das Technet konsultiert werden. Ebenso sollte für die Wiederherstellung ein Passwort verwendet werden, das extern gespeichert wird und eine gewisse Komplexität besitzt.

DNS Delegierung

Da keine übergeordnete Zone vorhanden ist, kann die DNS Delegierung so belassen werden. -> Weiter

Netbios

Die Netbios-Namen sind in der Regel die Kurzform der oben gewählten Domäne ohne Endung (.local) in Großbuchstaben geschrieben.

Speicherpfad

Der Speicherpfad der Datenbankdateien kann vorerst so belassen werden. Im Normalfall wird jedoch auf einem externen Volume, das speziell gesichert ist (RAID,…) gespeichert.

Zusammenfassung

Die Einstellungen werden vor dem Prüfen nochmals aufgezeigt. -> Weiter

Prüfungsergebnis

Das Prüfungsergebnis wird nochmals aufsummiert. Warnungen sind hier normal, nicht erschrecken. -> Installieren

Installprogress

Während der Installation muss kurz gewartet werden.After Installation

 

logoff

Nach der Installation wird kurz zusammengefasst und dann vom Server abgemeldet. Dies kann/soll nicht umgangen werden, also wieder warten.

Login after DC elevation

Nach der Heraufstufung zum Domänencontroller steht ab sofort die Domäne vor dem Benutzer: VALHALLA\Administrator. -> Anmelden

DC status

Nach dem Neustart ist in den Systemeinstellungen ersichtlich, dass der Computer Mitglied in einer Domäne ist.

Check im Servermanager

Im Server-Manager kann nun auch das Fenster Active Directory-Benutzer und -Computer aufgerufen werden.

PDC ist in DC

Hier ist ersichtlich, dass der Computer als Domänencontroller hinterlegt ist. Die Installation ist somit verifiziert und fertig.

Windows Server 2012 R2 Netzwerkkarte konfigurieren

Zentral an jedem Server ist in der Regel die Möglichkeit zur Kommunikation mit anderen Endgeräten in einem Netzwerk. Hierzu gehört natürlich ein gewisses Grundwissen über Subnetting, das aber mittlerweile durch diverse Subnet-Calculator jedoch auch relativiert wird.

Bei einem Windows Server gibt es zwei grundsätzliche Möglichkeiten, die Netzwerkkarte zu konfigurieren:

  • Per grafischer Oberfläche (GUI)
  • Per CMD/Powershell (üblicherweise bei Server Core)

Konfiguration mit GUI

Zuerst soll die Netzwerkkarte per GUI konfiguriert werden.

Netzwerk- und Freigabecenter öffnen

Hierzu wird ein Rechtsklick auf das Netzwerk-Icon in der Taskleiste gemacht und das Freigabecenter geöffnet. Alternativ kann das Fenster auch über die CMD bzw. das Ausführen-Fenster geöffnet werden. Hierzu gibt es zwei mögliche Befehle:

  • ncpa.cpl

ncpa.cpl

  • control.exe /name Microsoft.NetworkAndSharingCenter

control.exe

Wichtig ist im Freigabecenter der Punkt „Adaptereinstellungen“. Hier werden die einzelnen Netzwerkkarten aufgelistet. Bei anderer Hardware werden hier auch Modems, WLAN-Adapter,… gelistet. Da diese hier jedoch keine Rolle spielen, sind diese nicht vorhanden.

NIC Settings

Die Einstellungen der Netzwerkkarte verstecken sich hinter den Eigenschaften.

NIC Options

Hier ist der vorhandene Netzwerkadapter ersichtlich und die Elemente, die die Hardware unterstützt. Hier können eventuell fehlende Elemente, die grundsätzlich jedoch unterstützt werden sollen, auch treiberabhängig fehlen. Für das hiesige Beispiel ist im Speziellen die Konfiguration des IPv4-Protokolls wichtig. Daher wird dieses markiert und ein weiteres Optionsmenü mit einem Klick auf Eigenschaften geöffnet.

Auto Config NIC

Im jetzt offenen Fenster sind die wichtigsten Einstellungen geöffnet. Hier ist nun zu sehen, dass IP-Adresse und DNS-Daten automatisch bezogen werden.
Hier soll eine feste IP-Adresse vergeben werden. Folglich wird der Radio-Button „Folgende IP-Adresse verwenden:“ ausgewählt und mit einer IP-Adresse gefüllt. In diesem Beispiel soll die IP-Adresse 192.168.216.1 verwendet werden und die Subnetz-Maske 255.255.255.0. Als DNS-Server werden die von Google als Beispiel verwendet. (8.8.8.8 und 8.8.4.4) In einem Heimnetzwerk ist der DNS-Server entweder vom Provider vorgegeben oder der Router. Eine Konstruktion, die standardmäßig die Google-DNS-Server verwendet ist auch möglich, sofern keine Auflösung lokaler Hostnamen erfolgen soll.

Configured IP

Die Einstellungen werden mit OK bestätigt. Das Fenster der Netzwerkkarte wird mit Schließen geschlossen. Die neuen Einstellungen sollen durch Analyse des NIC’s kontrolliert werden:

NIC status

Rechtsklick auf den Netzwerkadapter und dann auf Status.

NIC Details

Die aktuelle IP kann unter Details angesehen werden.

Aktuelle IP

Die Einstellungen wurden folglich korrekt übernommen. Alternativ kann – auch als schöner Übergang – mit der CMD der Befehl „ipconfig /all“ ausgeführt werden. Hier wird dann der entsprechende Netzwerkadapter anhand des Namens gesucht und die Analyse ergibt folgendes:

ipconfig /all

Hiermit ist auch von Consolen-Seite bestätigt, dass die korrekte IP-Adresse übernommen wurde.

Server Core

Eine weitere Möglichkeit der NIC-Konfiguration ist die Powershell. Zuerst muss das entsprechende Modul importiert werden – dies ist ab Powershell 3.0 durch das Autoloading-Feature normal nicht notwendig und dient hier der Vollständigkeit.

Import-Module NetAdapter

Dies wird mit „Import-Module NetAdapter“ realisiert.

Get-NetAdapter

Mit „Get-NetAdapter“ kann eine Liste der ganzen NIC’s angezeigt werden, die auf dem Server aktiv sind. Dieser soll als Parameter in der Powershell übernommen werden, dass auf diesen immer unmittelbar zurückgegriffen werden kann.

Adapter als Parameter

Wir geben folgenden Befehl ein:

$adapter1 = Get-NetAdapter -Name Ethernet0

Hierdurch wird alles nach dem = als Parameter $adapter1 gespeichert. Durch Eingabe von $adapter1 kann verifiziert werden, dass die Details von adapter1 (also Ethernet0) ausgegeben werden.

Disable DHCP

Im nächsten Schritt wird DHCP deaktiviert. Dies ist identisch mit dem Schritt oben, bei dem der Radio-Button für die automatische Zuweisung der IP-Adresse entfernt worden ist. Der Server wartet jetzt auf eine manuell zugewiesene IP-Adressen. Der Befehl hierzu ist:

$adapter1 | Set-NetIPInterface -Dhcp Disabled

 

New IPAddress

$adapter1 | New-NetIPAddress -AddressFamily IPv4 -IPAddress 192.168.216.1 -PrefixLength 24 -Type Unicast

Der Befehl jetzt ist etwas länger, im Detail bedeutet er folgendes:

Der Adapter $adapter1 bekommt eine neue IP-Adresse der Adressfamilie IPv4. Die IP-Adresse ist 192.168.216.1 und die Subnetzmaske (respektive PrefixLength) besteht aus 24 Netz-Bits, was umgeschrieben 255.255.255.0 besteht. Der Verbindungstyp ist üblicher Weise Unicast.

Bei den Netz-Bits ist zu beachten, dass von links nach rechts gezählt wird und jeder durch Punkte separierte Block für 8 Bits zählt. 255 ist der maximale Wert eines Blockes, was somit als „/8“ in der CIDR-Schreibweise niedergeschrieben werden kann. Durch 255.255.255.0 wären es 8+8+8 Bits, was dann 24 Bits (siehe PrefixLength) bedeuten würde und somit mit /24 bzw. 255.255.255.0 ausgeschrieben wird.

Was fehlt nun noch? Ach ja, die DNS-Server! 😉

DNS Powershell

Der DNS-Server kann wie folgt eingestellt werden:

$adapter1 | Set-DnsClientServerAddress -ServerAddresses 8.8.8.8,8.8.4.4

GUI-Check

Am Schluss die Kontrolle via GUI:

Passt alles perfekt.