Kategorie: Microsoft

Windows Server 2012 R2: Datei nach Dedeplizierung nur noch 0 Byte groß

Veröffentlicht 2. Juli 2014

In einem früheren Artikel habe ich beschrieben, wie man auf einem Windows Server 2012 die Datendeduplizierung (Data-Deduplication) konfiguriert und nutzt. Dort war in einem einfachen Beispiel zu sehen, dass die Datei nach der Deduplizierung noch genau 4KB belegt hat, also die verwendete Blockgröße (“Größe der Zuordnungseinheit”

Das liegt daran, weil die nach der Deduplizierung die verwendeten Chunks nicht mehr beim betroffenen File liegen. Die Datei ist also tatsächlich 0 Byte groß – belegt aber eigentlich an einer anderen Stelle Speicherplatz.

Mit Hilfe des PowerShell-Cmdlets “Measure-DedupFileMetadata” lässt sich die tatsächlich belegte SPeichermenge ermitteln:

Hier belegt die SizeOnDisk nur noch die zu erwartenden 4KB…

Die eigentlichen Chunks liegen im Ordner “System Volume Information”, an dessen Inhalt man aber nicht ohne Weiteres herankommt.

Schreibe einen Kommentar...

SCCM 2012: “Inboxes”-Verzeichnis füllt sich / Laufwerk läuft voll

Veröffentlicht 18. Juni 2014

Auf einem unserer SCCM-Server ist mir aufgefallen, dass sich das Laufwerk C:\, welches großzügig bemessen ist, nahezu komplett gefüllt hat. Eine einfach Analyse mit TreeSize brachte folgendes zum Vorschein:

Wie auf dem Screenshot zu sehen ist, hat das receive-Verzeichnis unter "C:\Program Files\Microsoft Configuration Manager\inboxes\despoolr.box\receive" eine beachtliche Größe bekommen. Aber was sind das nun für Dateien? Zuersteinmal kann man allgemein sagen, dass dies Daten sind, die auf dem lokalen Verteilungspunkt (“Distribution Point”, DP) verteilt werden sollten und hier während der Empfangs-Phase zwischengespeichert wurden. Aber um welches Paket handelt es sich?

Dazu kann man das Logfile bemühen. Unter “C:\Program Files\Microsoft Configuration Manager\Logs” liegen die verschiedenen Log-Dateien, für diesen Zweck zuständig ist die despool.log (oder auch despool.lo_, falls die ursprüngliche despool.log ihre maximale Größe erreich hatte). Öffnen kann man die Logdateien am besten mit dem SCCM-eigenen Tool “CMTrace”, welches unter "C:\Program Files\Microsoft Configuration Manager\tools\cmtrace.exe" zu finden ist. Dort kann man nun mittels des Fernglas-Symboles suchen:

Als Suchtext kann der Name der größeren Datei verwendet werden, hier also “PKGhl61p.TRY”. Dabei kommt dann auch der Paketname zum Vorschein:

Hier in diesem Fall also “CAS00045”. Nun kann man in der Configuration Manager Konsole unter “Überwachung / Verteilungsstatus / Inhaltsstatus” den Status für des betreffende Paket prüfen:

Da das Paket (mittlerweile) erfolgreich auf den lokalen DP kopiert wurde, kann man die *.TRY-Datei also löschen. Dass dies nicht automatisch vom System gemacht wurde, dürfte hier in diesem Fall daran liegen, dass die Verteilung über WAN auf Grund der Größe des Paketes mehrfach gescheitert ist…

Schreibe einen Kommentar...

SCCM 2012 R2: Timeout bei OSD-Fehlern von 15 Minuten auf beliebigen Wert erhöhen

Veröffentlicht 17. Juni 2014

Wenn es während einer Tasksequenz im System Center Configuration Manager 2012 R2 zu einem Fehler kommt, so wird die Fehlermeldung standardmäßig für 15 Minuten angezeigt – danach wird der Client neugestartet. Wenn man nun eine längere Tasksequenz laufen lässt, wird man selten die gesamte Zeit vor dem betroffenen Rechner verbringen und so auch die Fehlermeldung verpassen. Noch schlimmer wird es, wenn der Fehler noch vor dem Abschluss der Formatierung des Laufwerkes geschieht – denn bis zu diesem Punkt ist das Logfile lediglich in einer Ram-Disk abgelegt – und die ist beim Neustart natürlich weg!

Diese Fehlermeldungen sehen dann in etwa so aus:

Dieses Verhalten lässt sich glücklicherweise abändern – mit einem nicht all zu hohem Aufwand! Dazu muss lediglich in der betreffenden Tasksequenz (es geht leider nicht pauschal) eine Tasksequenzvariable gesetzt werden.

Dazu wird die Tasksequenz geöffnet und direkt an erster Stelle ein weiterer Schritt “Tasksequenzvariable festlegen” eingefügt:

Der Name der Variable lautet “SMSTSErrorDialogTimeout” – der Wert ist in Sekunden anzugeben:

Damit ist die gewünschte Änderung auch schon gemacht. Beim nächsten Start der Tasksequenz ist die gemachte Änderung auch schon wirksam… Und dann kann man im Falle eines Fehler mittels F8 die DOS-Box öffnen und beispielsweise mit “cmtrace.exe” die Logfiles analysieren.

1 Kommentar

SCCM 2012 R2: Logging während OSD verbessern

Veröffentlicht 15. Juni 2014

Während einer Betriebssysteminstallation (“OSD” – Operating System Deployment) werden alle Schritte protokolliert. Das Problem dabei ist, dass das Logfile dabei maximal 1MB groß werden darf. Alle älteren Einträge werden überschrieben. Und ein Megabyte ist selbst beim Standard-Loglevel nicht sehr viel…

Um die gewünschten Änderungen zu erreichen, müssen die Boot-Images (“boot.wim”) angepasst werden. Dabei muss eine Konfigurationsdatei erzeugt und in den Abbildern hinterlegt werden. Diesen Vorgang möchte ich hier etwas genauer beschreiben:

Als erstes besorgt man sich die aktuell verwendeten Startabbild-Dateien für 32 Bit und 64 Bit. Wo diese zu finden sind, kann man in den Eigenschaften der Abbilder nachsehen. ^

Der übliche Speicherort lautet

\\[HOSTNAME]\SMS_[SITECODE]\OSD\boot\i386\

für 32 Bit und

\\[HOSTNAME]\SMS_[SITECODE]\OSD\boot\x64\

für 64 Bit.

Als zweites benötigt man das Windows ADK in einer passenden Version. Dieses kann bei Microsoft heruntergeladen werden. (http://www.microsoft.com/de-de/download/details.aspx?id=39982)

Nun kann mit Hilfe von DISM in einer Eingabeaufforderung mit administrativen Rechten die jeweilige WIM-Datei zum verändern gemountet werden. Dies geschieht mittels des Aufrufes

dism /Mount-Wim /WimFile:C:\boot.wim\boot.CAS00005.wim /index:1 /MountDir:C:\boot.wim\mount_x64

(Die Pfade sind entsprechend anzupassen)

Nun kann im Windows-Pfad des gemounteten Images eine Datei mit Namen “SMSTS.INI” und folgendem Inhalt abgelegt werden:

[Logging]

LOGLEVEL=0

LOGMAXSIZE=10485760

LOGMAXHISTORY=3

DEBUGLOGGING=1

CCMDEBUGLOGGING=1

Das LogLevel 0 steht für “verbose”, ist also der höchste Detailgrad. Standard wäre 1…

LogMaxSize erklärt sich sicher von selbst – der Wert wird in Bytes angegeben (hier also 10MB)

LogMaxHistory sorgt dafür, dass nicht nur das letzte LogFile gelesen werden kann, sondern auch die vorherigen. Im Normalfall steht der Wert auf 1 und dabei werden ältere Logs immer durch das aktuelle überschrieben.

DebugLogging aktiviert das Protokollieren von Debug-Meldungen (1 ist “true”, 0 ist “false”)

CCMDebugLogging tut im wesentlichen das selbe, Microsoft empfiehlt die Verwendung beider Varianten, ich vermute aus Gründen der Abwärtskompatibilität

Die Namen der Konfigurationsparameter müssen in Großbuchstaben geschrieben werden!

Nun kann die WIM-Datei wird zurückgeschrieben werden, dazu dient wieder DISM mit folgendem Kommando:

dism /Unmount-Wim /MountDir:C:\boot.wim\mount_x64 /commit

Danach muss das WIM-File nur noch zurück auf den SCCM-Server kopiert werden und neu auf die Verteilungspunkte (“Distribution Points”) verteilt werden…

Schreibe einen Kommentar...

Windows 8.1 Benutzer ohne Frühjahrs-Update (Update 1) bekommen keine Patches mehr

Veröffentlicht 11. Juni 2014

Was Microsoft bereits im April angekündigt hatte (http://blogs.technet.com/b/askpfeplat/archive/2014/04/07/exploring-windows-8-1-update-start-screen-desktop-and-other-enhancements.aspx) wird nun Ernst:

Wer das Update 1 für Windows 8.1 aus dem April 2014 bisher nicht installiert hat, bekommt seit dem gestrigen Patch-Tuesday keine Updates für sein Betriebssystem mehr! (Das gilt natürlich auch für künftige Patches)

Daher sei an dieser Stelle noch einmal daran erinnert, dieses Update zu installieren und neben den folgenden Sicherheitsupdates auch von zahlreichen Verbesserungen zu profitieren. Einige davon hat mein Kollege Remigiusz Suskiewicz in seinem letzten Blogpost beschrieben.

Das Update 1 (KB2919355) bekommen Sie hier:

http://www.microsoft.com/de-de/download/details.aspx?id=42335

Schreibe einen Kommentar...

Erster Bericht über die TechEd North America 2014

Veröffentlicht 27. Mai 2014

Vom 12. bis 15. Mai 2014 fand in Houston, Texas die diesjährige Microsoft TechEd North America statt. Dies ist die größte Konferenz zu Microsoft-Produkten, im Schwerpunkt im ITPro-Bereich. Dieses Jahr wurde die TechEd mit dem MMS (Microsoft Management-Summit) zusammengelegt.

(Abbildung: Die Keynote wird von einer lokalen Band eingeleitet, welche moderne Rock- und Pop-Songs auf klassischen Instrumenten interpretierte)

Die Keynote, gehalten von Corporate VP Brad Anderson, gab einen recht guten Überblick über Microsofts aktuelle Strategie – es geht massiv um die Themen “Cloud” (Azure) und “People Centric IT” (hier z.B. Themen wie “Bring your own device” (BYOD) und die Anbindung von Nicht-Microsoft-Systemen an Microsoft-Landschaften). Das Motto war “Mobile-first, cloud-first world”. Weiterhin wurden einige Neuerungen für Azure angekündigt bzw. an diesem Tag freigegeben (z.B. “Express Route”, “Azure Files”, “Azure Site Recovery”, VMs neuer Größe, …). Glücklicherweise konnte ich einen der letzten Plätze erreichen. Der Raum, der zur Verfügung stand, reichte gefühlt gerade für die Leute, die ihre Hotels im direkten Umfeld des Convention-Centers hatten und somit nicht auf die Shuttle-Busse angewiesen waren, die sich jeden Morgen durch den Stau quälen mussten.

(Abbildung: Microsoft Corporate Vice President Brad Anderson on-stage während der Keynote)

Es gab 6 Tracks zu den Themen

“Data Plattform and Business Intelligence” (Datenbanken),
“Datacenter and Infrastructure Management” (Windows Server, System Center, Virtualisierung, PowerShell),
“Developer Plattform and Tools” (Entwickler),
“Office Servers and Services” (Office, Office 365, Exchange, Lync, Sharepoint),
“People-Centric IT” (Quer-Beet),
“Windows, Phone and Devices” (Windows 8.1, Windows Phone, App-V)

Die ca. 12.000 Teilnehmer (Es gibt keine offiziellen Angaben, zahlen schwanken zwischen 11.000 und 13.000) verteilten sich erstaunlich gut über die ca. 400 verschiedenen Sessions, welche von den unterschiedlichsten Personengruppen (Microsoft Product-Manager, Microsoft Technical Evangelists, Microsoft Technical Fellows (Also Nicht-MS-Mitarbeiter, die sehr stark mit Microsoft-Themen verbunden sind), MVPs, Drittanbieter) gehalten wurden. Obwohl es ständig Schlangen gab, insbesondere beim Essen und an den Toiletten, hat man es dennoch geschafft, diese völlig ausverkaufte Veranstaltung logistisch ganz ordentlich abzuwickeln.

Parallel zu den Sessions gab es im Erdgeschoss ständig die Möglichkeit, sich auf der TechExpo mit verschiedenen Microsoft-Partner-Firmen über deren Produkte und Lösungen aus dem Microsoft-Umfeld zu unterhalten. Zusätzlich konnte man in Hands-On-Labs oder Instructure-Lead-Labs erste praktische Erfahrungen mit neueren Microsoft-Produkten zu sammeln. Weiterhin gab es die Möglichkeit, zu reduzierten Preisen Microsoft-Prüfungen für eine Zertifizierung abzulegen.

Ein Highlight waren aus meiner Sicht vor allem die Sessions der MVPs, die im Stil von “Lessions Learned” ihre Erfahrungen mit den aktuellsten Microsoft-Produkten aus dem Einsatz in größeren Szenarien weitergaben. Dieses Sessions waren stets gut besucht, vollgepackt mit Know-How und nicht zuletzt auch sehr unterhaltsam. Eine der Sessions (PCIT-B410) wurde von 5 MVPs gehalten (“How many MVPs does it take to get a Powerpoint started?” war nach ersten Startschwierigkeiten im Twitter zu lesen), Thema war der System Center Configuration Manager. Hier saßen ca. 1000 SCCM-Administratoren in einem Raum – eine unglaubliche Fülle von Wissen, ergänzt durch die Ausführungen der MVPs Kent Agerlund, Johan Arwidmark, Greg Ramsey, Jason Sandys und Steve Thompson.

(Abbildung: Die MVPs von PCIT-B410 hatten sichtlich Spaß!)

In einem weiteren Beitrag werde ich in naher Zukunft noch auf einige Inhalte eingehen, welche ich von der Konferenz “mitgenommen” habe.

Alle Sessions können unter http://channel9.msdn.com/Events/TechEd/NorthAmerica/2014?direction=asc#tab_sortBy_day als PPTX und MP4 heruntergeladen werden.

Zu Houston selber muss man leider sagen: Das ist keine Stadt, die man als Tourist gesehen haben muss. Abgesehen von den zum Teil extrem heißen Temperaturen gibt es nicht viel zu sehen. Außerhalb kann man das NASA Space Center besichtigen, in der Stadt selber gibt es einen recht hübschen Zoo und einige nette Museen. Ansonsten ist insbesondere am Abend und am Wochenende nichts los, die Texaner selbst raten einem, bei Dunkelheit nicht mehr auf die Straße zu gehen.

(Abbildung: Die Skyline von Downtown Houston, betrachtet aus Richtung Brown Convention Center)

Schreibe einen Kommentar...

SCOM 2012 R2 – Auto-Defragmentierung

Veröffentlicht 15. Mai 2014

Wenn man den Operations Manager 2012 nutzt, dann wird man vermutlich auch schon einmal über eine Meldung gestolpert sein, die darauf hinweist, dass ein logisches Laufwerk zu stark fragmentiert ist („Fragmentierungsgrad des logischen Datenträgers ist hoch“ / „Logical Disk Fragmentation Level is High“). Wenn man viele Server überwacht, dann wird man diese Meldung auch sehr oft sehen – ganz speziell am Montag Morgen (das liegt daran, dass die Standardeinstellung dieses Monitor dafür sorgt, dass der Test immer Samstag 03:00 Uhr läuft).

Nun hat man im Wesentlichen 3 Optionen:

Meldung hinnehmen und von Hand auflösen – bedeutet u.U. sehr viel Aufwand
Meldung ignorieren oder gar mittels Override deaktivieren – löst aber nicht die Ursache auf
Meldung nutzen, um nicht nur die Meldung selbst (=Wirkung), sondern auch den Zustand (=Ursache) selbst aufzulösen

Die Möglichkeit, die Defragmentierung zu automatisieren ist auch im Wissensdantenbank-Artikel des Monitors erwähnt:

Wie das genau geht, hat Cameron Fuller, MVP für SCOM, in seinem Blogartikel beschrieben:

http://tinyurl.com/OMAutodefrag

Ein großartiger Artikel!

Update: Es gibt auch einen etwas einfacheren Weg – man kann das selbe Ziel auch mit einem einfachen Override erreichen, somit ist auch kein weiteres MP nötig… Wie genau das funktioniert, werde ich zeitnah nachreichen.

Schreibe einen Kommentar...

BranchCache mit Windows Server 2012 R2 und Windows 8.1

Veröffentlicht 5. Mai 2014

BranchCache, eine Technologie die mit dem Windows Server 2008 R2 und Windows 7 eingeführt wurde, ermöglicht es, den Datenverkehr auf WAN-Strecken und die damit einhergehende Wartezeit bei der Übertragung zu reduzieren. Es geht darum, den lesenden Zugriff von einem Unternehmens-Standort (hier als “Filiale” bezeichnet) auf Daten in einem anderen Standort (hier als “Firmensitz” bezeichnet) zwischen zu speichern (“caching”).

Grundsätzlich stehen zwei verschiedene Modi zur Verfügung:

Hosted Cache (“Gehosteter Cache”)
Distributed Cache (“Verteilter Cache”)

Beim Hosted Cache übernimmt ein Server in der Filiale die Aufgabe des Caches. Er speichert die Daten entsprechend zwischen. Beim Distributed Cache wird auf einen dedizierten Server verzichtet – die Clients der Filiale übernehmen das Caching. Vorteil des Distributed Cachings ist also der Verzicht auf zusätzliche Hardware und den damit verbundenen Verwaltungsaufwand. Allerdings entsteht der Nachteil, dass das Endgerät, welches die Daten in seinem Cache hält, zum benötigten Zeitpunkt nicht online ist und somit der Cache nicht genutzt werden kann.

Es existieren mittlerweile zwei verschiedene Versionen:

V1 steht bereits ab Windows Server 2008 R2 und Windows 7 zur Verfügung
V2 steht erst ab Windows Server 2012 und Windows 8 zur Verfügung

Der Ablauf beim Distributed Cache ist (etwas vereinfacht) der folgende:

Client1 in der Filiale soll ein File auf einem Dateiserver am Firmensitz öffnen; durch eine GPO ist er für BranchCache und den Modus “Distributed Cache” konfiguriert. Beim Dateiserver fragt er nicht die Datei selber sondern deren Hash (eine Art Fingerabdruck, die das File in seiner aktuellen Version identifiziert) an.
Der Dateiserver überträgt den Hash zum Client1 (Der Hash wurde vom Dateiserver generiert, dieser ist ebenfalls durch eine GPO entsprechend konfiguriert)
Client1 fragt per Broadcast in seinem Subnetz an, ob andere Clients das File in ihrem Cache haben, welches durch den Hash identifiziert wird; im Beispiel gehen wir nun davon aus, dass keiner der anderen Clients dieses File bisher geöffnet hat
Client1 fragt nun noch einmal beim Dateiserver an; dieses Mal jedoch direkt nach der Datei statt nach deren Hash
Die Datei wird zum Client1 übertragen und dort geöffnet
Wenn nun auch Client2 in der Filiale diese Datei öffnen will, dann beginnt der Prozess wieder “von neuem”: Client2 fragt beim Dateiserver den Hash für das File an
Der Dateiserver überträgt den Hash an Client2
Client2 fragt per Broadcast in seinem Subnetz nach dem Hash
Client1 meldet sich, da dieser das File in seinem Cache hat (Voraussetzung ist, dass sich das File zwischenzeitlich auf dem Dateiserver nicht geändert hat, denn dann hätte es einen anderen Hash!); Die Datei wird nun aus dem Cache von Client1 zum Client2 übertragen; dieser kann das File nun öffnen (und er hält es fortan auch in seinem Cache vor!)

Dabei haben also folgende Übertragungen stattgefunden:

2x Abfrage des Hashes über WAN
1x Übertragung des Files über WAN
1x Übertragung des Files über LAN

Eingespart wurde also die zweite Übertragung des Files über WAN; stattdessen kommt die Übertragung der Hashes hinzu, die aber im Verhältnis deutlich kleiner sind

BranchCache ist also insbesondere sinnvoll bei:

Unternehmen mit verschiedenen Standorten
Häufigen lesenden Zugriffen auf sich selten ändernde Dateien über das gesamte Unternehmensnetzwerk

Die Edition des Server-Betriebssystems spielt bei einem Server 2012 R2 keine Rolle, bei den Clients muss unter Windows 8.1 die Enterprise-Edition eingesetzt werden. (Unter Server 2008 R2 muss der Caching-Server mindestens die Enterprise-Edition verwenden, für den Dateiserver spielt die Edition keine Rolle; Windows 7 Clients müssen mindestens die Enterprise-Edition verwenden.)

Im Folgenden möchte ich den Aufbau einer einfachen BranchCache-Umgebung darstellen. Dabei gibt es einen Server, SRV1, der neben der Aufgabe des Domänen-Controllers auch gleichzeitig die Aufgabe des Dateiserver übernimmt. Die beiden Clients WIN8-1 und WIN8-2 werden dann den Zugriff auf eine Datei des Dateiservers durchführen.

Auf SRV1 wird über den Servermanager / “Verwalten” / “Rollen und Features hinzufügen” ein Rollendienst hinzugefügt:

Unterhalb der Rolle “Datei-/Speicherdienste” findet sich “BranchCache für Netzwerkdateien”:

Nach der Installation dieses Rollendienstes kann nun an jeder Freigabe, bei der dies gewünscht ist, BranchCache aktiviert werden. Dies geschieht in den Eigenschaften der “Erweiterten Freigabe” über den Button “Zwischenspeichern”:

Als nächstes müssen nun zwei Gruppenrichtlinien konfiguriert werden:

CPR_BranchCache_Content ist für den Fileserver gedacht und wird sinnvollerweise über die Sicherheitsfilter nur auf diese angewendet
CPR_BranchCache_Clients ist für die Clients gedacht und kann z.B. per WMI-Filter dynamisch auf diese wirken

Innerhalb der Content-Policy wird zum einen die Hash-Veröffentlichung aktiviert und zum anderen die Version festgelegt. Man kann hier zwischen “Nur V1”, “V1 und V2” oder “Nur V2” wählen:

Der relevante Pfad innerhalb der GPO lautet “Computerkonfiguration” / “Richtlinien” / “Administrative Vorlagen” / “Netzwerk” / “LanMan-Server”

Innerhalb der Client-Policy sind etwas mehr Einstellungen vorzunehmen:

Hier muss BranchCache aktiviert werden, der Modus “Verteilter Cache” festgelegt werden und optional können die maximale Speicherbelegung, das maximale Alter und weitere Dinge konfiguriert werden. Aus Demo-Zwecken werde ich außerdem in der Einstellung “BranchCache für Netzwerkdateien konfigurieren” die minimale Latenz von 80ms auf 0ms herabsetzen und somit das Nutzen des Caches auch in einem schnellen Netzwerk erzwingen:

Sinnvollerweise wird nun auf dem Server und den Clients ein gpupdate durchgeführt, um nicht erst auf das Verarbeiten der GPOs warten zu müssen:

Nun kann man auf den Clients noch einmal die Branchcache-Konfiguration überprüfen. Dies geschieht mit Hilfe des Aufrufes

netsh branchcache show status all

Sollte dann in etwa so aussehen:

Nun kann mittels Leistungsüberwachung getestet werden, ob die Konfiguration funktioniert. Dazu sind die entsprechenden Indikatoren hinzuzufügen:

Sinnvollerweise schaltet man nun die Leistungsüberwachung auf “Bericht” um (drittes Symbol in der Leiste oben von links gezählt).

Der Benutzer “Franz Iskaner” öffnet nun von WIN8-1 aus ein Dokument auf dem Dateiserver:

Eine Eigenart des integrierten PDF-Readers auf WIndows 8 ist, dass dieser das Dokument nur in Teilen öffnet und beim Lesen dann entsprechend die Inhalte nachlädt. Daher wurde nun also nicht das gesamte Dokument mit ca. 13MB sondern nur ein Teil davon vom Server abgerufen (ich habe die ersten hundert Seiten von ca. 2000 durchgeblättert):

Auf WIN8-2 öffnet nun “Karl Auer” das selbe Dokument, die Leistungsüberwachung ist geöffnet und zeigt nun folgende Werte auf WIN8-2:

(WIN8-1 hatte zwischenzeitlich weitere Teile des Dokumentes abgerufen, weshalb WIN8-2 etwas mehr vom Cache abrufen konnte als WIN8-1 im oberen Screenshot vom Server abgerufen hatte)

Ein Teil des Dokumentes kommt hier (das aber insbesondere wegen des PDF-Readers) immer noch vom Server – nämlich der Teil, der nicht im Cache auf WIN8-1 liegt, weil er dort bisher nicht geöffnet wurde.

Die Funktionsfähigkeit der BranchCache-Konfiguration ist damit aber gezeigt.

An dieser Stelle sei nochmal darauf hingewiesen, das BranchCache nur LESEND funktioniert – beim Schreiben wird direkt auf den Server geschrieben und nicht in den Cache!

Weitere Informationen zum Thema Branchcache finden sich im Microsoft Technet:

http://technet.microsoft.com/de-de/library/hh831696.aspx

Schreibe einen Kommentar...

Windows Server 2012 R2: Automatische Sperre verhindern

Veröffentlicht 23. April 2014

Im Gegensatz zu seinen Vorgängern sperrt der Windows Server 2012 R2 seine Oberfläche nach 10 Minuten Inaktivität. Dies ist aus Sicherheitsgründen sicherlich nützlich, oft aber einfach nur störend, z.B. wenn man einen Prozess längere Zeit beobachten will oder vor allem in Test- und Demoumgebungen.

Selbstverständlich lässt sich dieses Verhalten abschalten, allerdings etwas versteckt.

Das Ganze geschieht über die Energieeinstellungen und dort in den jeweiligen Energiesparplaneinstellungen:

Systemsteuerung / Hardware / Energieoptionen (oder direkt im Startmenü “Energieoptionen” eingeben. Dort werden als erstes die Energiesparplaneinstellungen des aktuellen Energiesparplanes geöffnet.

Hier muss dann über “Erweiterte Energieeinstellungen ändern” die GUI für die Energieoptionen geöffnet werden.

Allerdings hat die notwendige Option einen eher unerwarteten Namen:

Das was hier an der deutschen Oberfläche als “Bildschirm ausschalten nach” bezeichnet wird, betrifft auch das Sperren der Sitzung. Standardmäßig sind hier 10 Minuten eingetragen. Ein Herabsetzen auf den Wert “0” deaktiviert diese Funktion komplett.

Schreibe einen Kommentar...

Exchange 2007 lässt sich nicht via Windows Server Sicherung sichern

Veröffentlicht 18. März 2014

Hinweis: Bei meinen Recherchen zu dem Thema habe ich festgestellt, dass dieses Problem scheinbar auch bei Exchange 2010 auftritt!

Bei einem Exchange Server 2007 mit LCR trat seit längerem das Problem auf, dass sich dieser nicht sauber (auf Anwendungsebene) sichern ließ. Die Windows Server Sicherung meldete immer

“Abgeschlossen mit Warnungen – Die Anwendung kann aus dieser Sicherung nicht wiederhergestellt werden […]”

Kurz nach Start der Sicherung findet sich im Ereignisprotokoll folgender Eintrag:

Anwendungsprotokoll / Ereignis 565 / Quelle Backup / “Fehler bei der Konsistenzprüfung für die Komponente […]”

Eine Überprüfung der Postfachdatenbank sowie der Datenbank für die öffentlichen Ordner und aller Logs mit Hilfe von ESEUtil brachte keinerlei Fehler oder sonstige Probleme.

Als Lösung des Problemes habe ich den Exchange VSS-Writer per Registry deaktiviert.

Dazu ist unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\Replay\Parameters ein neuer DWORD-Schlüssel anzulegen, der den Namen “EnableVSSWriter” und den Wert 0 bekommt.