Microsoft hat mit Visual Studio Code seinen ersten Multiplattform Editor (Windows, Mac OSX und Linux) veröffentlicht, welcher nach meiner Meinung duchaus einen Blick wert ist:
https://code.visualstudio.com/
Enjoy it, b!
Im Zuge des im nächsten Jahr anstehenden Windows Server 2016 Releases, wollte ich meine Testumgebung wieder auf Vordermann bringen. Die beiden Server sind zwar CPU und RAM seitig gut ausgestattet aber eine 1,5TB Samsung SATA Platte war dann doch ein wenig knapp und darum wollte ich beide Systeme mit einem RAID Controller und 4x4TB Festplatten versehen. Aus den Platten will ich einen RAID 10 bauen (damit es ordentlich läuft) und darauf neben einem primären System mit Hyper-V noch mehrere Boot-from-VHD Instanzen laufen lassen … für die 8TB finden wir also schon Verwendung.
Der LSI Controller (inzwischen ein AVAGO / LSI 9240-4i Controller) war zusammen mit den Platten schnell eingebaut, kein Problem und auch das RAID war schnell erstellt Auf diesem RAID habe ich dann ein Volume mit 64GB gelegt und dieses im RAID Controller BIOS als “Bootable” markiert.
Danach kann die Installation des Betriebssystems beginnen, bei mir wie so oft Microsoft Hyper-V Server 2012 R2.
Leider wurde mir das Volume als Platte nicht im Setup angezeigt:
Für alle die jetzt denken “ließ mal richtig” … der Treiber ist INBOX, sprich Windows bringt einen Treiber mit, welchen man hinterher nur aktualisieren muss. Aber OK, ISO gebaut und über das IPMI Board den Treiber bereit gestellt … selbes Ergebnis – keine Platte.
Nach gefühlten 100 Konfigurationen im BIOS des Servers, mehrfachen löschen des RAIDs hatte ich mich entschlossen einen Call sowohl bei Supermicro als auch bei LSI/Avago zu öffnen. Da der Controller problemlos funktionierte wollte ich nicht so recht an einen Defekt der Hardware glauben.
Supermicro konnte mir hier nicht weiterhelfen (obwohl die Lösung hinterher bei denen lag). Aber der Support war schnell und sehr freundlich.
LSI hingegen dauert immer relativ lange – 4-5h zwischen den Mails, aber letztendlich kam von dort der richtige Hinweis:
Darauf habe ich mich entschlossen das BIOS des Servers zu aktualisieren, danach hat es auf Anhieb mit der Installation von Hyper-V Server 2012 R2 geklappt.
Hier noch die Daten dazu:
Controller: Avago / LSI 9240-4i, FW Package 20.12.1-0150, Firmware 2.130.394-2550, 4.36 Build March 25, 2013
Motherboard: Supermicro X10SLM+-F, BIOS 3.0, x10slh5_424.ZIP
Das Update des Motherboard BIOS war die Lösung. Nachdem der Server dann lief, habe ich sofort den LSI Controller ebenfalls mit dem aktuellsten BIOS versorgt.
Enjoy it, b!
In den Home-Editionen von Windows hat Microsoft das Benutzer-Management eingeschränkt. So ist es z.B. nicht so einfach möglich einem Benutzer Konto das Ablaufen des Passworts ab zu gewöhnen. In den Pro-Editionen läßt sich das in den Eigenschaften des Kontos konfigurieren:
In den Home-Editionen bleibt nur die Möglichkeit über das WMI (was natürlich auch in den Pro-Editionen bzw. in Skripten möglich und hilfreich ist).
WMIC USERACCOUNT WHERE "Name='Support'" SET PasswordExpires=FALSE
Damit läßt sich auch in den Home-Editions ein Account ohne ablaufendes Passwort konfigurieren.
Update 2015-12-18:
Für einen Domain Account geht das natürlich auch, allerdings verwende ich in diesem Fall die dstools welche auf einem AD Controller vorhanden sind:
dsquery user domainroot -name "USERNAME" | dsmod user -pwdneverexpires YES
Enjoy it, b!
Seit dem 18.11.2015 gibt es WireShark in der Version 2.0!
https://www.wireshark.org/#download
Enjoy it, b!
Dieser Beitrag behandelt gleich zwei Probleme welche ich mit dem Azure Backup Client auf Windows Server 2008 R2 hatte.
… error when you try to install the Microsoft Azure backup agent
Dafür liefert Microsoft sogar einen KB, wichtig ist hier das genau die im Artikel referenzierte VC Komponente verwendet wird und nicht etwa ein Update davon.
https://support.microsoft.com/en-us/kb/2934202
Danach klappt’s auch hier mit dem Backup. Interessanter ist jedoch das folgende Problem – und dessen Lösung.
Nach der Installation des Azure Backup Clients ist unter Verwendung korrekter Tresoranmelde-Daten (Vault Credentials) keine Verbindung zu Azure Backup möglich. Die Netzwerkeinstellungen sind aber OK, der Server ist mit dem Internet verbunden!
Wenn die obigen Vorraussetzungen zutreffen, sollten einmal die Internet-Einstellungen des System-Accounts geprüft werden! Der Azure Backup Service läuft nämlich unter Local System und hat damit eigene Proxy-Einstellungen, welche möglicher Weise verändert wurden:
An diese gelangt man durch einen Aufruf des Internet Explorers durch psexec im Kontext von Local System.
psexec -i -s "C:\Program Files\Internet Explorer\iexplore.exe"
In dem nun gestartetem Internet Explorer kommt man über Extras / Internet Optionen / Verbindungen / LAN-Einstellungen zum Proxyserver welcher in diesem Fall konfiguriert war!
Hier alle Einstellungen raus nehmen und schon klappt es mit der Registrierung des Servers.
Update:
Optional kann man auch die Liste erweitern für die kein Proxyserver verwendet wird.
Hierzu die folgenden Einträge hinzufügen:
https://*.windows.net;https://*.windowsazure.com
Enjoy it, b!
Aus einem Blogbeitrag von Microsoft geht hervor, dass auch das große November Update mit dem Client Connector des Windows Server Essentials zusammen arbeitet.
Ich selbst konnte bisher keine Probleme mit Windows 10 1511 und dem SBS Essentials Connector feststellen. Daher immer fleißig updaten 
Update 18.11.2015:
Kaum hat man einen Beitrag geschrieben, schon gibt’s etwas Neues:
The update to support auto-redirection of Windows Server 2012 R2 Essentials for Windows 10 client connector is now available at:
https://support.microsoft.com/en-us/kb/3105885
Enjoy it, b!
Meine Vorliebe für den Windows Server Core und vor allem den Microsoft Hyper-V Server dürfte bekannt sein. Das Arbeiten auf diesen System ist sehr mit der Kommandozeile behaftet, egal ob PowerShell oder die cmd.exe Verwendung finden.
Wenn irgendwie möglich setzte ich in meinen Server immer RAID-Controller von LSI (inzwischen Avago) ein. Der Weg dahin war vorgezeichnet:
Genug der Geschichten … der Update eines LSI Controllers auf Windows Server Core ist kein Hexenwerk, es müssen drei Komponenten aktualisiert werden.
Die entsprechenden Pakete findet man auf der Avago Homepage und können dort herunter geladen werden. Die Links stammen vom Updates eines LSI MegaRAID 9261-8i.
Unter Support Documents and Downloads auf der Avago Homepage (http://www.avagotech.com) folgende Suche absetzen:
Alle Downloads entpacke ich in das Verzeichnis c:\temp\lsi – für die jenigen welche auf dem Server Core keine unzip.exe haben, einfach lokal entpacken und auf den Server drauf kopieren.
Das sieht dann wie folgt aus:
Wieso LSI den Storage Manager 2x verpackt hat, erschließt sich mir nicht – dennoch, irgendwann taucht mal die setup.exe auf.
Für uns sind hier nun folgende Dateien wichtig:
Im ersten Schritt machen wir ein Update des MegaRAID Storage Managers. Dabei werden, in dieser Version zumindest, alle Einstellungen gelöscht (also auch die Benachrichtigung per Email) welche im Anschluss dann wieder gesetzt werden müssen.
Dazu einfach c:\temp\lsi\msm\disk1\setup.exe starten und sich durch den Wizard klicken.
Der Storage Manager läßt sich danach über das folgende Script starten.
C:\Program Files (x86)\MegaRAID Storage Manager\startupui.bat
Diese Datei kopiere ich unter einem anderen Namen (mr.cmd) in folgendes Verzeichnis c:\program files\script (mit diesem ich die Pfad Variable erweitert habe) und nehme dazu folgende Modifikationen vor:
@Echo off :: mr.cmd rem %~d0 rem CD %~dp0 pushd "%ProgramFiles(x86)%\MegaRAID Storage Manager" start JRE\bin\javaw -DVENUS=true -classpath .;GUI.jar;monitorgui.jar;DebugLog.jar;log4j-1.2.15.jar;jaxen-1.1.jar;jdom-1.1.jar GUI.VivaldiStartupDialog ajsgyqkj=71244 popd
Damit kann ich den Raid Manager von jedem beliebigen Verzeichnis aus starten.
Nun kann über den MegaRAID Storage Manager das Update der Controller Firmware vorgenommen werden.
Was bei LSI Controllern meistens online – also ohne einen Neustart erfolgen kann.
Zum Ende kommt nun noch die Installation des Windows-Treibers, welches ich über pnputil.exe erledige. Dazu muss ich in das Verzeichnis mit dem richtigen Treiber (win8.1_x64 = Windows Server 2012 R2) wechseln und folgenden Aufruf durchführen:
pnputil -i -a MegaSAS2.inf
Damit der Treiber dann auch geladen wird, ist allerdings ein Neustart notwendig. Mit SigCheck.exe aus den Sysinternals Tools läßt sich dann auch die Version des geladenen Treibers ermitteln.
C:\Temp>"\Program Files (x86)\Windows Sysinternals Tools\sigcheck.exe" C:\Window
s\system32\DRIVERS\megasas2.sys
Sigcheck v2.30 - File version and signature viewer
Copyright (C) 2004-2015 Mark Russinovich
Sysinternals - www.sysinternals.com
c:\windows\system32\drivers\megasas2.sys:
Verified: Signed
Signing date: 12:10 PM 9/10/2015
Publisher: Avago Technologies U.S. Inc.
Company: Avago Technologies
Description: MEGASAS RAID Controller Driver for Windows
Product: MEGASAS RAID Controller Driver for Windows
Prod version: 6.709.12.00
File version: 6.709.12.00
MachineType: 64-bit
Falls nicht geschehen, nochmals das Alerting (per Emails) konfigurieren.
Enjoy it, b!
… There is insufficient disk space in the cache volume. Please ensure that at least 2.5GB of free space exists in the cache volume.
Das Problem rührt daher, dass der Cache für das Backup by default unter folgendem Pfad liegt C:\Program Files\Microsoft Azure Recovery Services Agent\Scratch und bei entsprechend großen Datenmengen einfach das Sytemlaufwerk zu müllt.
Seit einiger Zeit bietet der Azure Client die Möglichkeit an, im Verlauf der Installation das Verzeichnis für den Cache zu ändern. Auf großen Fileservern – dieser hier hat 3TB lege ich dafür eigens eine VHDx an (Laufwerk X) und lassen den Cache auf dieser werkeln. Im Verlauf der Neuinstallation habe ich damit X:\Microsoft Azure Recovery Services Agent\Scratch als Pfad für den Cache verwendet.
Der Backupclient ist hier übrigens ein wenig zickig, sprich das Verzeichnis muss manuell erstellt werden, der Wizard kann das nicht.
md "X:\Microsoft Azure Recovery Services Agent"
Der gesamte Ablauf sieht wie folgt aus:
Zur Registrierung sind die Vault Credentials notwendig, welche aber nach deren Erstellung nur 2 Tage Gültigkeit haben. Daher müssen, falls die Einrichtung des Azure Backups länger als 2 Tage zurück liegt, neue Credentials aus dem Portal herunter geladen werden. Der Wizard spricht hier von “we recommend” … was aber Blödsinn ist, sind die Vault Credentials abgelaufen – geht es mit der Registrierung nicht weiter.
Die Vault Credentials (Tresoranmeldedaten) sind hier zu finden.
Microsoft Azure Portal / alle elemente / Name = Kundenname / Typ = Sicherungstresor
Die neuen Vault Credentials speichere ich (obwohl nur 2 Tage gültig) zusätzlich nochmals ab und kopiere sie auf den entsprechenden Server C:\Users\Public\Documents\Azure von dort kann sie dann der Register Server Wizard ohne Probleme laden und fordert zur erneuten Eingabe der Passphrase ein – hier nehme ich die ehemals verwendete und speichere diese wiederum in meinem lokalen Azure Verzeichnis ab.
Natürlich ist es nicht sinnvoll die PassPhrase lokal auf dem Server zu belassen. Das komplette Azure Verzeichnis wird komprimiert und außerhalb der Firma an einem sicheren Ort gespeichert.
Mit dem Start lädt der Azure Backup Agent auch die vorherige Konfiguration und zeigt die vorhandenen Sicherungen an – so wollten wir das ja auch haben.
„Ich liebe es, wenn ein Plan funktioniert!“ (für die jüngern Leser – https://de.wikipedia.org/wiki/Das_A-Team)
Damit ist der Azure Backup Client korrekt konfiguriert! Allerdings müssen wir uns an dieser Stelle noch für das vollgelaufene Systemlaufwerk kümmern:
rd "C:\Program Files\Microsoft Azure Recovery Services Agent\Scratch" /s /q
Danach sind auf Laufwerk C: wieder 50GB (in diesem Fall frei).
Wichtig:
Für den Fall, dass die Netzwerkbandbreite beschränkt wird (was während der Arbeitszeit mehr als sinnvoll ist) müssen diese Einstellungen erneut gesetzt werden. Diese sind hier verloren gegangen.
Update 02.11.2015:
Ohne eine Neuinstallation des Azure Clients läßt sich der Pfad für das Scratch-Verzeichnis auch über die Registry ändern. Dazu sind folgende Schritte notwendig:
net stop obengine
md "X:\Microsoft Azure Recovery Services Agent"
HKLM\SOFTWARE\Microsoft\Windows Azure Backup\Config, ScratchLocation, X:\Microsoft Azure Recovery Services Agent HKLM\SOFTWARE\Microsoft\Windows Azure Backup\Config\CloudBackupProvider, ScratchLocation, X:\Microsoft Azure Recovery Services Agent
net start obengine
Enjoy it, b!
Gleich auf drei meiner Windows Server 2012 R2 Essentials Servern hat die Zeitumstellung am vergangenen Wochenende zu folgendem Effekt geführt.
Das Problem läßt sich durch einen Neustart des Servers, oder ein wenig ““professioneller”, durch einen Neustart des Windows Server Essentials Management Service lösen.
net stop "Windows Server Essentials Management Service" && net start "Windows Server Essentials Management Service"
Enjoy it, b!
Für die Migration von verschiedenen Small Business Server Versionen auf Windows Server 2012 R2 stellt Microsoft einen Guide zur Verfügung, welchen ich auch im Rahmen meiner Migrationen verwende.
https://technet.microsoft.com/en-us/dn408633.aspx
Der Guide ist in 8 Schritte unterteilt welche die wesentlichen Punkte einer Migration beschreiben:
Im Verlauf meiner Migrationen habe ich einige Punkte anders gemacht, welche ich hier darstellen möchte, Zuerst jedoch eine Überlegung zu wirklich kleinen Umgebungen 
Kleine SBS Umgebungen (so um die 5 Benutzer) migriere ich gar nicht. Hier führe ich eine Neuinstallation des SBE durch und übertrage anschließend Benutzereinstellungen mit Windows Easy-Transfer in die neue Domain. Das funktioniert auch recht gut, wenn über den Server zentral bereitgestellte Anwendungen lediglich eine Dateifreigabe benötigen (die Arztpraxis lässt da grüßen). Diese Variante stellt einen sauberen Neuanfang dar – ohne Altlasten. Gibt es jedoch in der Umgebung mehr als nur 5 Benutzer und dazu noch Anwendungen, dann ist eine Migration sinnvoll und damit die Abarbeitung der 8 oben beschriebenen Schritte.
Für größere und/oder komplexere Umgebungen migriere ich natürlich …
Die Grundlage für die folgenden Empfehlungen war eine Umstellung von Windows Small Business Server 2008 Premium auf Windows Server 2012 R2 Essentials. Neben dem Small Business Server mit Exchange 2007 gab es noch folgende Anwendungen:
Die Umstellung habe ich in 4 Schritten gemacht:
Wie man Mails in die Cloud, bzw. nach Office365 transferiert beschreibt Microsoft hinreichend genau und soll hier auch nicht weiter ausgeführt werden. Da die Mailboxen in Summe für 6 Benutzer die 100GB Grenze erreicht hatten und die Anbindung an das Internet mit ADSL (16MBit/s Down und 1MBit/s Upload) nicht gerade üppig ist, habe ich mich auf eine Migration von Kontakten und Kalendern beschränkt. Die Mails verbleiben in der zu Mailarchivierung verwendeten Lösung Mailstore und sind über ein Plugin in Outlook vorhanden. Von dort kann dann jeder Benutzer selbst wichtige Mails in sein neues Postfach transferieren.
Die Migration auf den neuen Server habe ich wie folgt gemacht.
Nach diesen Schritten sollte der alte SBS Server nur noch die Anmeldung machen, alle anderen Dienste laufen zu diesem Zeitpunkt auf dem installierten Member-Server! Diese Vorgehensweise bietet mir ausreichend Zeit um die Funktion des neuen Servers zu testen. Können die Benutzer damit eine Woche problemlos arbeiten, dann kommt der nächste Schritt – Umstellung der Domäne.
Move-ADDirectoryServerOperationMasterRole -Identity "sbe.sbsland.local" -OperationMasterRole 0,1,2,3,4
Mit einer Zeile PowerShell ist das eine sehr coole Sache.
So, nun geht’s ans Aufräumen … ob das notwendig ist oder nicht, muss jeder selbst entscheiden. Ich versuche zumindest die migrierte Domäne, wie eine neu installierte erscheinen zu lassen. Dabei geht es im Wesentlichen um folgende Punkte.
Um Exchange 2007 zu deinstallieren sind im Wesentlichen die folgenden Schritte aus der TechNet zu beachten:
https://technet.microsoft.com/en-us/library/bb123893(v=exchg.80).aspx
Bei jeder bisher von mir durchgeführten Migration, bin ich auf die folgenden drei Fehler gestoßen welche die Deinstallation von Exchange 2007 verhindert haben. Daher habe ich diese in einem extra Blog-Beitrag beschrieben:
https://sbsland.wordpress.com/2016/03/07/entfernen-von-exchange-2007-im-verlauf-einer-migration/
Danach ließ sich wie im TechNet-Artikel beschrieben Exchange 2007 deinstallieren.
Die Benutzer und Gruppen verschiebe ich nach \Users und alle Computer (egal ob Server oder Clients) nach \Computers im Active Directory. Unterschiedlichen Anforderungen bzgl der Einstellungen werden über GPOs und Gruppen realisiert:
Damit die MyBusiness OU gelöscht werden kann, muss noch die Erstellung von Benutzer und Computerkonten in den unteren OUs deaktiviert, bzw. wieder zurück nach \Users und \Computers gestellt werden. Dazu gibt es zwei Befehle:
# redirusr CONTAINER-DN redirusr cn=users,dc=sbsland,dc=local # redircmp CONTAINER-DN redircmp cn=computers,dc=sbsland,dc=local
Nach der Migration der Benutzer von den “alten” Gruppen in neue, können diese gelöscht werden. Das erfolgt wiederum in zwei Schritten:
@echo off :: net group /dom | findstr /i "Windows SBS" >groups-2-delete-from-2008.cmd :: Group Accounts for \\SBS net group "SBS Admin Templates" /dom /delete net group "SBS Fax Operators" /dom /delete net group "SBS Folder Operators" /dom /delete net group "SBS Mail Operators" /dom /delete net group "SBS Mobile Users" /dom /delete net group "SBS P User Templates" /dom /delete net group "SBS Remote Operators" /dom /delete net group "SBS Report Users" /dom /delete net group "SBS SP Admins" /dom /delete net group "Windows SBS Fax Administrators" /dom /delete net group "Windows SBS Fax Users" /dom /delete net group "Windows SBS Folder Redirection Accounts" /dom /delete net group "Windows SBS Link Users" /dom /delete net group "Windows SBS Remote Web Workplace Users" /dom /delete net group "Windows SBS SharePoint_MembersGroup" /dom /delete net group "Windows SBS SharePoint_OwnersGroup" /dom /delete net group "Windows SBS SharePoint_VisitorsGroup" /dom /delete net group "Windows SBS Virtual Private Network Users" /dom /delete
und
@echo off :: net group /dom >groups-2-delete-to-be-standard.cmd ::Group Accounts for \\SBS :: ------------------------------------------------------------------------------- :: *_ SBSland Client Computers //-Kunde-// :: *_ SBSland Desktop Admins //-Kunde-// :: *_ SBSland Folders Redirect //-Kunde-// :: *_ SBSland Hyper-V Hosts //-Kunde-// :: *_ SBSland Mailstore Users //-Kunde-// :: *_ SBSland Office //-Kunde-// :: *_ SBSland Terminal Server Users //-Kunde-// :: *Cloneable Domain Controllers //-WS2012R2-// :: *DnsUpdateProxy //-WS2012R2-// net group "Domain Power Users" /dom /delete :: *Domänen-Admins //-WS2012R2-// :: *Domänen-Benutzer //-WS2012R2-// :: *Domänencomputer //-WS2012R2-// :: *Domänencontroller //-WS2012R2-// :: *Domänen-Gäste //-WS2012R2-// :: *Enterprise Read-only Domain Controllers //-WS2012R2-// net group "Exchange Domain Servers" /dom /delete :: *Organisations-Admins //-WS2012R2-// - Enterprise Admins :: *Protected Users //-WS2012R2-// :: *RDP_MAPPING_S-1-5-21-966628382-784051496-1200022492-1531 :: *RDP_MAPPING_S-1-5-21-966628382-784051496-1200022492-2846 :: *RDP_MAPPING_S-1-5-21-966628382-784051496-1200022492-4661 :: *RDP_MAPPING_S-1-5-21-966628382-784051496-1200022492-4662 :: *RDP_MAPPING_S-1-5-21-966628382-784051496-1200022492-4667 :: *RDP_MAPPING_S-1-5-21-966628382-784051496-1200022492-4683 :: *Read-only Domain Controllers //-WS2012R2-// :: *Richtlinien-Ersteller-Besitzer //-WS2012R2-// - build-in :: *Schema-Admins //-WS2012R2-// net group "User Roles" /dom /delete net group "Web Workplace Users" /dom /delete :: *WseAlertAdministrators //-WS2012R2-// :: *WseAllowAddInAccess //-WS2012R2-// :: *WseAllowComputerAccess //-WS2012R2-// :: *WseAllowDashboardAccess //-WS2012R2-// :: *WseAllowHomePageLinks //-WS2012R2-// :: *WseAllowMediaAccess //-WS2012R2-// :: *WseAllowShareAccess //-WS2012R2-// :: *WseInvisibleToDashboard //-WS2012R2-// :: *WseManagedGroups //-WS2012R2-// :: *WseRemoteAccessUsers //-WS2012R2-// :: *WseRemoteWebAccessUsers //-WS2012R2-// :: The command completed successfully.
Nun kann die MyBusiness OU gelöscht werden und auch die Gruppen entsprechen dem Standard einer neuen Installation.
Nicht vergessen sollte man an dieser Stelle die Bereinigung der GPOs des SBS 2008 inkusive der alten WMI Filter (grün umrandet).
Hier ein kleiner Tipp zu den GPOs – vielleicht erst einmal deaktivieren, bevor man sie löscht.
Zum Abschluss wird der alte SBS Server mit DCPromo aus dem AD entfernt und herunter gefahren. Da nach dem DCPromo der alte SBS ein Member-Server ist, lasse ich ihn erst einmal ausgeschaltet und deaktiviere das Computerkonto. Nach 14 Tagen, lösche ich dieses und dazu auch noch die VM (die VHDs mit Daten kann man ja noch behalten … falls man was vergessen hat).
That’s it
Enjoy it, b!
Windows SBS and Essentials Blog 