Drücke "Enter", um den Text zu überspringen.

Haikos Blog Posts

PowerShell: Anmelde-Konto der Windows-Dienste überprüfen

Wenn auf einem Windows Server Dienste nicht mit dem richtigen Konto gestartet werden, können diverse Fehler auftreten, z.B. der Fehler 1079:

pwservices1

Der Fehler entsteht, wenn mehrere Konten unter dem selben Prozess (z.B. svchost) laufen, dabei aber verschiedene Konten nutzen sollen.

Nun muss man also herausfinden, welche Dienste betroffen sind. Dies geht sicherlich auch über die services.msc (also in der GUI) – ist dann aber mit viel Arbeit verbunden. Einfacher wäre es sicherlich, dies über PowerShell herauszufinden.

Leider kennt das Cmdlet “Get-Service” keine Möglichkeit, die Logon-Werte auszugeben:

pwservices2

Selbst der Aufruf “Get-Service | fl *” zeigt kein passendes Attribut:

pwservices3

Was bleibt nun also? Eine Abfrage mittels WMI!

pwservices4

Und tatsächlich – hier gibt es nun ein Attribut “StartName”, welches das verwendete Konto enthält. Nun kann man also eine einfache Liste aller Dienste mit ihren Konten abrufen:

pwservices5

Will man statt den “internen” (teil kryptischen) Dienstnamen die sprechenden Namen sehen, und auch nach diesen sortieren, dann kann man folgenden Aufruf verwenden:

Get-WmiObject win32_service | Sort-Object Caption | ft Caption,StartName

pwservices45

Über Where-Object kann man nun auch gezielt nach Diensten mit einem bestimmten Konto suchen:

pwservices7

Schreibe einen Kommentar...

Windows Server 2012 R2: Netzwerk-Profil mit PowerShell von “Öffentlich” auf “Privat” ändern

Oft kommt es vor, dass ein Windows Server das Netzwerk-Profil (Domäne oder Privat) nicht sauber erkennt und stattdessen auf “Öffentlich” steht. Dies hat natürlich Auswirkungen, z.B. auf die gesetzten Firewall-Regeln:

fw0

Eine kurze Überprüfung im “Netzwerk- und Freigabecenter” fördert das gleiche Ergebnis zu Tage:

fw1

Auch mit Hilfe der Windows PowerShell kann man dies sehen…

fw2

… und ändern!

fw3

Mit Hilfe des Aufrufs

Set-NetConnectionProfile –InterfaceIndex # –NetworkCategory Private

wird das Verbindungsprofil auf “Privat” gesetzt (“Domain” setzt auf Domäne). Nun kann man auch im Netzwerk- und Freigabecenter das korrekte Verbindungsprofil sehen:

fw4

3 Comments

WDS und SCCM oder 2x WDS parallel betreiben / Probleme mit PXE lösen

Wenn man (z.B. während der Einführungsphase vom System Center Configuration Manager) den bisherigen WDS-Server (Windows Bereitstellungsdienste / Deployment Services) weiterhin nutzen will, aber parallel die Betriebssystembereitstellung (OSD) von SCCM benötigt, dann besteht im Wesentlichen das folgende Probleme:

Da PXE auf Broadcasts basiert, kann es nur einen PXE-Server geben, den der Client letztlich kontaktiert (man kann per Verzögerung dafür sorgen, das einer immer schneller ist als der andere). Wenn man nun also PXE am SCCM aktiviert, dann ist es quasi Glückssache, ob der Client zuerst die Meldung vom WDS oder zuerst die von SCCM empfängt – in den meisten Tests war SCCM schneller. Damit bleibt also nur eine der beiden Technologien nutzbar.

Aber es gibt eine Lösung! Diese ist leider a) nicht wirklich dokumentiert und b) seitens Microsoft auch nicht unterstützt (man hört aber, das selbst Microsoft diese Lösung intern einsetzen soll).

Die Lösung besteht darin, dem Benutzer am Client die Wahl zu lassen, welchen der gefundenen PXE-Server er nutzen will. Um dies zu erreichen, ist am WDS-Server (also derjenige, der nicht der SCCM-Server ist) ein Registry-Key zu setzen:

pxe1

Zusätzlich muss am SCCM in den eigenschaften des Distribution-Points (Verteilungspunkt) für eine ausreichende Verzögerung gesorgt werden (würde man zuerst den PXE vom SCCM booten, dann hat der RegKey dort keine Wirkung, da dieser nur auf den WDS-eigenen PXE-Provider wirkt, nicht aber auf den vom SCCM):

pxe5

Wenn nun ein Client einen PXE-Boot versucht (und die Verzögerung ausreichend war, dass sich zuerst der Nur-WDS-PXE-Server meldet), dann bekommt der Benutzer zusätzlich zu der Möglichkeit, per F12 vom Netzwerk zu booten eine weitere Option: F11 für eine Server-Auswahl!

pxe2

Drückt man jetzt F12, wird wie gewohnt DIESER WDS-Server genutzt und von dort mittels PXE gebootet. Drückt man jedoch F11, werden zuerst alle verfügbaren WDS-Server erkannt:

pxe3

Danach bekommt man eine Auswahl-Liste mit allen gefundenen PXE-Servern:

pxe4

Hier kann nun der jeweilige PXE-Server gewählt werden. Der WDS-Server selber steht an erster Stelle, an zweiter Stelle steht hier der SCCM mit aktiviertem PXE.

Auf diese Weise ist es möglich, WDS und SCCM oder mehrere WDS-Server parallel zu betreiben. Natürlich muss die entsprechende DHCP-Infrastruktur aufgebaut sein, damit PXE überhaupt funktionieren kann!

Schreibe einen Kommentar...

WIndows 8.1 Update 2 und Windows 9 – erste Gerüchte

Update: Windows 9 wird offiziell „Windows 10“ heissen…

Aktuellen Gerüchten zufolge soll im August 2014 das Update 2 für Windows 8.1 kommen, Dieses soll auch Voraussetzung für ein späteres Upgrade auf Windows 9 sein, liefert wohl aber nicht das erhoffte Startmenü wieder zurück. Dieses wird wohl erst in Windows 9 enthalten sein, welches voraussichtlich im Herbst 2015 final erscheinen soll. Vermutlich wird dann also im Herbst 2014 eine erste Vorabversion (“Preview”) erhältlich sein.

Im neuen Windows 9 kehrt das Startmenü dann wie von vielen Kunden gewünscht zurück – allerdings nur auf Geräten ohne Touchscreen. Hier wird es auch nicht möglich sein, den Startscreen von Windows 8 zu nutzen. Dafür lässt sich das neue Startmenü dann wohl auch vergrößert darstellen und die Modern Style UI Apps laufen dann in der “Desktop-Welt”. Auf Touch-Geräten wird wohl weiterhin das Menü aus Windows 8 enthalten sein.

t1-f9a18ec5da6206e5

(Abb.: So könnte das neue (“alte”) Startmenü in Windows 9 auf Nicht-Touch-Geräten aussehen)

Zeitgleich mit dem Release von Windows 9 wird wohl auch Windows 365 starten – ein neues Modell, bei dem man das Betriebssystem nicht kauft, sondern in einem Abo mietet. Gerüchten zufolge soll Windows 9 für Besitzer von Windows 8.1 kostenlos sein, für den Rest schlägt der reguläre Kauf wohl mit einem Preis von etwa 80€ zu Buche. Hier muss man sehen, was das Abo-Modell im Vergleich kosten wird.

Schreibe einen Kommentar...

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

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”

dedup_2012r2_1

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:

dedup_2012r2_2

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.

dedup_2012r2_3

Schreibe einen Kommentar...

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

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:

inboxes1

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:

inboxes2

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

inboxes3

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:

inboxes4

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

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:

SCCM_0x80070002

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:

sccm_ts_var

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

sccm_ts_var2

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

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. ^

Screenshot (18)

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)

Screenshot (13)

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

Screenshot (15) 

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

Screenshot (14)

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

Screenshot (17)

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

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

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.

DSC05218

(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.

DSC05257

(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.

DSC05358

(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.

DSC05584

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

Schreibe einen Kommentar...