Nachdem Microsoft durch http://support.microsoft.com/kb/2762663 die Installation der WSUS Rolle auf einem Windows Server 2012 Essentials wieder ermöglicht, bin ich auf ein weiteres Problem gestoßen. Nach erfolgreicher Installation und Konfiguration des WSUS (auf Laufwerk D:, sprich D:\WSUS) erscheint ein Alert im Dashboard des Windows Server 2012 Essentials, welcher als Lösung der Verschieben des WSUSTemp Ordners auf ein anderes als das Systemlaufwerk empfiehlt:

Das Problem liegt darin begründet das auf dem Windows Server 2012 Essentials keine Fileshares auf dem Laufwerk C (Systemlaufwerk) liegen sollten und der Server das auch überwacht. Leider ist ein Umzug des Fileshares auf ein alternatives Laufwerk nicht so ohne weiteres möglich, da WSUS 4.0 den lokalen Pfad als Download-Verzeichnis verwendet, also nicht etwa \\server\wsustemp, sondern explizit “C:\Program Files\Update Services\LogFiles\WSUSTemp” – was ein umlegen des Shares unmöglich macht. Zumindest ist mir keine Konfigurationsmöglichkeit innerhalb des WSUS bekannt um das entsprechende Verzeichnis zu ändern.

Insofern bleibt uns zur Lösung dieses Alerts nur die Option “Ignore this Alert” im Dashboard und ein gelegentlicher Blick in den Download-Ordner um ggf. darin enthaltene Reste manuell zu löschen.

Enjoy it, b!

Bisher war es leider nicht möglich den Windows Update Services (WSUS) als Rolle auf einem Windows Server 2012 Essentials zu installieren. Dieses Problem hat nun Microsoft mit einem Hotfix behoben:

http://support.microsoft.com/kb/2762663

Enjoy it, b!

Nachdem der Windows Server 2012 Essentials die Nachfolge der legendären Small Business Server Reihe angetreten hat, migriere ich so nach und nach meine Kunden dort hin. Letztendlich heißt die Kombination immer Office365 + Windows Server 2012 Essentials…

Im Verlauf der aktuellen Migration ist mir dabei folgendes aufgefallen. Das Hinzufügen der DHCP Server-Rolle hat nicht geklappt und ist mit folgender Fehlermeldung abgebrochen:

Da das nicht der erste Fall ist, wo ich mit dem DHCP-Server meine liebe Müh und Not hatte, hier die einfache Lösung dazu:

Ein Deaktivieren der Netzwerkkarte reicht aus, damit die Installation korrekt durch läuft. Auf einem Physikalischen Server habe ich das Netzwerkkabel abgezogen, bei Virtuellen Maschinen (VMs, was bei mir gut 99% der Installationen aus macht) reicht es den Virtuellen Switch unter Hyper-V von der VM zu disconnecten.

Was Euch der Server mit einer erfolgreichen Installation der Rolle dankt

Enjoy it, b!

Mit dem gestrigen Patchday (11.12.2012) hat Microsoft das Update Rollup Package 4 für den Small Business Server Essentials 2011 veröffentlicht, welches neben einigen Problemen auf der Server Seite auch eine Update für die Client Komponenten mit sich bringt. Bei mir hat die Installation auf dem Server, als auch der Update der Clients problemlos geklappt.

Anbei noch der Link zum Microsoft Knowledgebase Artikel: http://support.microsoft.com/kb/2757007/en-us

Enjoy it, b!

Nachdem ich einen Computer recovered habe und diesen (erneut in die Domain) und zum Small Business Server 2011 Essentials hinzugefügt hatte, tauchte dieser auf einmal doppelt auf meiner Anmelde Seite auf:

Alles hinzufügen und wegnehmen des Computers in den Benutzereigenschaften im Dashboard hat nichts geholfen. Der Eintrag blieb hartnäckig bestehen (um genauer zu sein, er tauchte immer doppelt auf oder halt gar nicht).

Die Lösung war letztendlich folgende Vorgehensweise:
Der SBE speichert die Remote Web Access Konfiguration in folgendem Verzeichnis:

C:\ProgramData\Microsoft\Windows Server\Data\settingsproviderdata\RemoteAccess\UserProfile“

Die dort enthaltene index.xml beinhaltet die Benutzer welche Zugriff auf die Remote Web Access Seite haben und eine entsprechende GUID, dieser korrespondiert wiederum mit einer XML-Datei mit dem entsprechendem Namen im gleichen Verzeichnis:

<?xml version=“1.0″?>
<ArrayOfString xmlns:xsd=“http://www.w3.org/2001/XMLSchema“ xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance„>
  <string>xxx\user1</string>
  <string>1ee0d2b6-39b7-4b8a-80cf-8c97e3de6202</string>
  <string>xxx\user2</string>
  <string>b704c337-ac62-4646-82f2-373ea7fcceed</string>
</ArrayOfString>

In meinem Fall war es user1, und somit öffnente ich die 1ee0d2b6-39b7-4b8a-80cf-8c97e3de6202.xml und fand dort den doppelten Eintrag:

  &lt;string&gt;MOR..&lt;/string&gt;
  &lt;string&gt;tal..&lt;/string&gt;
  &lt;string&gt;mor..&lt;/string&gt;

Den doppelten Eintrag habe ich einfach als ganze Linie entfernt und der Spuk war vorbei

Enjoy, it!

Nachdem am letzten Dienstag auch für Windows Server 2012 einige Updates veröffentlich wurden, wollte ich diese auf meinen Hyper-V Hosts installieren. Die manuelle Installation schlug jedoch fehl – und endete mit einer Aufforderung den Server neu zu starten. Eine Installation der Updates erfolgte nicht!

Meine erste Idee war “dann installieren wir halt manuell” – also die Updates runter geladen und mit wusa.exe die Installation initiert, was wiederum in folgender Fehlermeldung endete:

Den Fehlercode 0x80246003 (hex) nach dezimal (-2145099773) konvertiert und in der wuerror.h gesucht brachte folgendes Ergebnis:

WU_E_DM_UNKNOWNALGORITHM                                       wuerror.h

A download manager operation could not be completed because the file metadata requested an unrecognized hash algorithm.

Weder Bing noch Goolge lieferten hierzu weitere Infos ….

Ein erster Blick in die ReportingEvents.log Datei brachte folgendes Ergebnis:

{27814256-B1B9-4299-90F0-75F715B05E6B}    2012-11-15 06:07:12:756+0100    1    147 [AGENT_DETECTION_FINISHED]    101    {00000000-0000-0000-0000-000000000000}    0    0    (null)    Success    Software Synchronization    Windows Update Client successfully detected 6 updates.
{7E979BF4-40BB-4F82-AAA4-B3EB6913DB1A}    2012-11-15 06:07:12:756+0100    1    156 [AGENT_STATUS_30]    101    {00000000-0000-0000-0000-000000000000}    0    0    (null)    Success    Pre-Deployment Check    Reporting client status.
{9A5A83E2-74F7-4808-9820-1849827DC345}    2012-11-15 06:07:17:826+0100    1    161 [AGENT_DOWNLOAD_FAILED]    101    {8697530D-D5FB-42BF-B0CA-8B1D37FC0909}    104    80246003    (null)    Failure    Content Download    Error: Download failed.
{64D57906-1FC6-462B-8345-21484B979FF4}    2012-11-15 06:07:58:855+0100    1    161 [AGENT_DOWNLOAD_FAILED]    101    {2502CD17-FC89-43FC-B4B9-A79CB139DEF0}    100    80246003    (null)    Failure    Content Download    Error: Download failed.
{A97C0694-6FE9-4DC4-A116-CF38ECA168EF}    2012-11-15 06:07:59:073+0100    1    161 [AGENT_DOWNLOAD_FAILED]    101    {F0919BB9-349C-417C-93CF-799BD026636D}    100    80246003    (null)    Failure    Content Download    Error: Download failed.
{A42D73E1-A9F3-4FD0-974D-2450779ADC08}    2012-11-15 06:08:01:023+0100    1    161 [AGENT_DOWNLOAD_FAILED]    101    {7A56146F-0FB9-49EA-BDE9-7F121BDC4F1E}    102    80246003    (null)    Failure    Content Download    Error: Download failed.
{586EB18D-B968-4922-BA93-81B927DB8E4C}    2012-11-15 06:08:01:397+0100    1    161 [AGENT_DOWNLOAD_FAILED]    101    {6F1DA768-A02E-4358-8577-15299222255A}    101    80246003    (null)    Failure    Content Download    Error: Download failed.
{CEF086F9-71F4-4F26-B5A1-308F10423D6F}    2012-11-15 06:08:12:505+0100    1    161 [AGENT_DOWNLOAD_FAILED]    101    {BCFFEAAA-EA49-4959-BC0F-AB64408FBC98}    100    80246003    (null)    Failure    Content Download    Error: Download failed.

Nun gut, offensichtlich weden die 6 Updates erkannt – aber der Download schlägt fehl. Da der Hyper-V Server 2012 am internen WSUS hängt, habe ich mal dort rein geschaut und festgestellt das die Betriebssystem Version (anstatt Hyper-V 2012 bzw. Windows Server 2012) als Windows Server 2003 R2 ausgewiesen wurde. Sprich der WSUS schickt möglicher Weise Updates für Windows Server 2003 an den Hyper-V Server.

Die folgenden Schritte brachten dann eine Lösung des Problems:

1. Entfernen des Hyper-V Servers aus der Update Policy im AD
2. gpupdate / force und Kontrolle des WindowsUpdate.log ob auch wirklich kein interner WSUS hier im Spiel ist
3. Stoppen von Windows Update
4. Umbenennen des SoftwareDistribution Ordners (c:\Windows\SoftwareDistribution)
5. Start von Windows Update
6. Passt – über den Menüpunkt 6 des Hyper-V Servers können nun wieder Updates herunter geladen – und vor allem installiert werden

Update (20.11.2012)
Damit der WSUS 3.0 Windows Server 2012, Hyper-V 2012 und auch Windows 8 unterstützt, muss das Update aus KB2734608 (http://support.microsoft.com/kb/2734608?wa=wsignin1.0) installiert werden.

Enjoy it, b!

Für alle welche die verschiedenen Microsoft Technologien mal testen wollen gibt es den TechNet Evaluation Center http://technet.microsoft.com/en-us/evalcenter/default

Für Windows Server 2012 sind dort genauso ISO und VHDs (Hyper-V) zu finden wie für Windows 8. Darüber wurde mit Windows Server 2012 die Möglichkeit eingeführt eine Eval durch Eingabe eines Produkt-Schlüssels in eine Vollversion zu wandeln.

Enjoy it, b!

Microsoft hat einen Konverter für VMware basierende VMs vorgestellt. Das Tool ist kostenlos und konvertiert neben der Virtual Hard Disk auch wesentliche Teile der Konfiguration:

http://blogs.technet.com/b/scvmm/archive/2012/09/18/free-tool-to-convert-vmware-based-virtual-machines-and-disks-to-hyper-v-based-virtual-machines-and-disks.aspx

Enjoy it, b!

Anbei ein kleiner Auszug über die Uptime eines Hyper-V R2 Hosts:

Der Server steht in einem isoliertem Netzwerk (somit wird nur spärlich gepatched)… Aus Gründen der Stabilität muss man also einen Windows Server nicht jede Woche neu starten

Update 2012-10-05, der hier ist noch älter …

Enjoy it, b!

Kürzlich hatte ein Kunde von mir das Problem das ein Entfernen des Exchange Servers aus seiner Small Business Domain (SBE, Small Business Server 2011 Essentials) fehlgeschlagen ist. Wichtig, und an dieser Stelle gleich vorneweg – die Deinstallation von Exchange über Add/Remove Programs ist von Microsoft der einzige unterstützte Weg.

Da der Exchange Server aber durch einiges rumprobieren so verbogen war, dass eine normale Deinstallation nicht mehr funktionierte, blieb uns nur noch der Weg manuell zu versuchen die Reste aus dem Active Directory (AD) zu entfernen. Das waren im Wesentlichen die folgenden Schritte:

• Entfernen des alten SBS aus der Domain mittels DCPROMO
• Entfernen der Exchange 2010 Erweiterungen aus dem AD

Herunterfahren des Exchange Servers und löschen dessen Computerkontos und DNS Einträge. Da es sich hier um den “alten” SBS handelte, haben wir uns die Bereinigung des Betriebssystems gespart und die VM einfach weggeworfen! Falls der DCPROMO ebenfalls nicht mehr hingehauen hat, hier noch die Möglichkeit den alten SBS aus dem AD zu kratzen: http://support.microsoft.com/kb/216498

Zusätzlich mussten noch aus dem Active Directory die Erweiterungen von Exchange entfernt werden. Dazu haben wir folgende Schritte durchgeführt:

1. Vollsicherung des neuen SBE Servers
2. Öffnen von ADSIEDIT (wer es nicht hin bekommt, braucht die folgenden Schritte erst gar nicht zu machen
3. In ADSIEDIT Rechtsklick und hier Connect to … auswählen
4. Nun zum Default Naming Contect verbinden
5. Folgende Objekte suchen und löschen:
   DC=Domain,DC=Com -> OU=Microsoft Exchange Security Groups
   DC=Domain,DC=Com -> CN=Microsoft Exchange System Objects
6. In ADSIEDIT Rechtsklick und nun Connect to … auswählen
7. Nun zur Configuration verbinden
8. Folgende Objekte suchen und löschen:
   CN=Configuration,DC=Domain,DC=Com -> CN=Services -> CN=Microsoft Exchange
   CN=Configuration,DC=Domain,DC=Com -> CN=Services -> CN=Microsoft Exchange Autodiscover

That’s it – da wir im SBS / SBE Umfeld in der Regel nur einen Domain Controller haben brauchen wir uns über Synchronisation im AD keine Gedanken machen.

Wie schon oben erwähnt, ist dieser Weg not supported!

Enjoy it, b!