Weisheiten - der Netz-Weise Blog

Der SQL-Server MVP Brent Ozar hat ein eine gespeicherte Prozedur names sp_blitz zur Verfügung gestellt, mit der ein SQL-Server im Schnelldurchgang auf gängige Probleme überprüft werden kann. SP_Blitz ist kostenlos, kann direkt auf dem SQL-Server implementiert oder über ein kleines Programm aus dem Internet heruntergeladen und ohne Installation ausgeführt werden. Verwenden sie das aufführbare Tool, wird auch gleich ein pdf generiert. Die Dokumentation mit Problembeschreibungen und die möglichen Schritte zur Behebung finden Sie ebenfalls Brent Ozars Website. Ebenfalls auf der Website finden Sie auch sp_blitzIndex zur Analyse von Indexen. 

Wenn eine Windows-Anmeldung lange dauert, könnte dies an den abzuarbeitenden Gruppenrichltinien liegen. Lesen Sie hier, wie sie die Laufzeit der Gruppenrichtlinien bestimmen können. Die Anmeldung eines Clients kann mitunter sehr, sehr lange dauern. Eine der möglichen Ursachen für eine verzögerte Anmeldung bilden die Windows Gruppenrichtlinien.  Grundsätzliche Kandidaten für verzögerte Anmeldungen sind:

• Synchrone Verarbeitung (Alle Gruppenrichtlinien müssen komplett verarbeitet sein, bevor dem Benutzer die Arbeitsumgebung zur Verfügung gestellt wird)
• Anmeldescripte
• aufwändige WMI-Filter

Um die Abarbeitungszeit von Gruppenrichtlinien zu bestimmen, gibt es zum einen von Daren Mar-Elia (dem gpo-guy) das Kommandozeilenprogramm gptime.exe, dass die für die letzte Gruppenrichtlinienverarbeitung benötigte Zeit pro gpo anzeigt. Für eine ausführliche Analyse bietet Microsoft das Performance Toolkit im Windows ADK (Assessment and Deployment Kit) an. Das ADK kann man bei Microsoft herunter laden. Eine gute Einführung in die Analyse des Startvorgangs mit dem ADK bietet die Aufzeichnung der Teched-Session How many coffess can you drink while Windows 7 boots?   

Um unter Office 365 eine Email-Weiterleitung einzurichten, melden Sie sich unter Outlook.office365.com mit Ihrem mail-Konto an. Klicken Sie oben rechts auf das kleine Zahnrad-Symbol, um in die Einstellungen zu kommen. Wählen Sie "Optionen" aus, und im folgenden Fenster im rechten Bereich "Ihre emails weiterleiten".

Um von Ihrem Android oder Windows Phone aus auf Office 365 zuzugreifen, nutzen Sie Active Sync.Gehen Sie unter Android in "Konto hinzufügen", wählen Sie "Exchange Server", und geben Sie Ihr Office 365 mail-Konto ein. Der Name des Exchange-Servers, den Sie eintragen müssen, lautet "Outlook.office365.com". Danach erhalten Sie eine Sicherheitsbenachrichtigung, die sie einmal bestätigen müssen, und der Zugriff ist eingerichtet. http://office.microsoft.com/en-us/office365-suite-help/set-up-email-on-an-android-phone-or-tablet-HA102823196.aspx

Ist ein Windows-User Mitglied zu vieler Gruppen, kann es zu Anmeldeproblemen kommen. Wir erklären warum, und wie man die Problematik angehen kann. Mit der Migration von Windows NT4 auf Windows 2000 und neuere Betriebssyteme hat Microsoft ein Feature namens SID-History eingeführt. Wird ein Benutzer migriert, so werden seine Gruppenmitgliedschaften der alten Domäne in das neue Benutzerobjekt in der neuen Domäne übertragen, so dass der Benutzer nach wie vor auf die Resourcen der alten Domäne zugreifen kann. Wird diese SID-History nicht gelöscht, kann es früher oder später zu Anmeldeproblemen kommen, da die Menge der Gruppen, die in einem Access-Token hängen dürfen (dem "Personalauweis", der beim Anmelden an jedem Windows-Recher zur Authentifizierung erzeugt wird), beschränkt ist. Es gibt 2 beschränkende Faktoren, und zwar die maximale Größe in Byte, die auf dem Rechner eingestellt ist (max. 64 KB, ab Windows Server 2012 / Windows 8 48 KB) und die maximale Anzahl der Gruppen, in denen ein Konto Mitglied sein darf (1015). Die SID-History kann komplett oder auch punktuell gelöscht werden. Werkzeuge hierfür bietet z.B. Powershell. Einen genauen Artikel von Ashley McGlone, der zeigt, wie das mit Powershell zu bewerkstelligen ist, findet sich hier:

https://blogs.technet.com/b/ashleymcglone/archive/2011/11/23/how-to-remove-sid-history-with-powershell.aspx?Redirected=true

Hintergrundinfos zum Thema sowie eine Beschreibung, wie Sie einzelne SID´s filtern können, gibt es hier:
http://blog.joeware.net/2011/11/20/2338/

Wenn der Failover-Cluster-Manager mit dem Fehler "A weak event is created..." abstürzt, gibt es keinen Grund zur Panik. Es handelt sich um einen Bug in einem automatisch eingespielten Hotfix des .net-Framework. Abhilfe schafft ein weiteres Hotfix, dass man direkt bei Microsoft herunter laden kann. http://www.microsoft.com/en-us/download/confirmation.aspx?id=36468

Eine ganze Reihe von Powershell-Commandlets haben einen Parameter -Credential, der es erlaubt, ein Commandlet über das Netzwerk unter anderen Benutzerrechten zu starten. Das Commandlet Get-Credential liefert das hierzu notwendige Powershell Credential Objekt, das den Benutzernamen und das Kennwort für die Anmeldung enthält. Will man die Benutzerinformationen aber nicht interaktiv abfragen, sondern Scripten, hilft das interaktive Get-Credential nicht weiter. Stattdessen kann man aber die Benutzerinformationen in eine Datei speichern. Will man die Benutzerinformationen einfach in der gleichen Benutzersitzung weiterverwenden, kann man die Benutzerinformationen einfach an Export-CliXML weiterleiten: 

$user = Get-Credential 
$user | Export-CliXML C:\temp\user.xml

Dieser Befehlt ruft Benutzerinformationen ab und leitet diese direkt in die XML-Datei user.xml um. Die Daten werden allerdings vom System verschlüsselt und sind nur unter dem Benutzer wiederverwendbar, der die Datei angelegt hat. Das ist in den seltensten Fällen hilfreich. Um das Kennwort sicher und aus anderen Sitzungen verwenden zu können, helfen die Commandlets ConvertFrom-SecureString und ConvertTo-Securestring weiter. Mit Ihnen kann das vom System mit den Benutzerinformationen verschlüsselte Kennwort in ein mit AES verschlüsselten String umgewandelt bzw. wieder in einen Secure-String zurückgewandelt werden.  Um das Kennwort eines Benutzers zu verschlüsseln und in einer Datei zu speichern:

$user = get-Credential
$user.password | ConvertFrom-Securestring -Key (1..16) | out-file .\Password.txt

Um die Daten zu reimportieren:

$user = "nw\Holger"
$pw = get-content .\Password.txt | ConvertTo-Securestring -key (1..16)
$Cred = New-Object System.Management.Automation.PSCredential $user, $Password

ConvertFrom-Securestring nimmt das vom System gesicherte Kennwort, entschlüsselt und sichert es erneut mit AES. -Key übergibt den symmetrischen Schlüssel, mit dem das Kennwort gesichert wird. Der Schlüssel muß 128, 192 oder 256 Bit lang sein, daher muß das Kennwort aus 8, 12 oder 16 Zeichen bestehen. Die Zeichen werden in Form eines Byte-Arrays übergeben. Das sehr einfache Beispiel gilt nur Demo-Zwecken und sollte in der Praxis nicht nachgeahmt werden, denn (1..16) erzeugt ein Array von Zahlen von 1 bis 16. ConvertFrom-Securestring wandelt das Kennwort wieder zurück in einen Secure Key. Mit New-Object wird ein neues Benutzerobjekt erzeugt und ein Benutzername und das Kennwort als Secure String übergeben. Damit können die Credentials jetzt auch unter einem anderen Benutzerkonto verwendet werden. 

Wenn Sie ein Powershell-Script in eine sich selbst ausführende Datei umwandeln wollen (.exe), gibt es dafür eine Reihe von Möglichkeiten. Eine davon ist das Tool PS2EXE auf Codeplex, eine andere Variante ist ein Script von Keith Hill, dass allerdings die Powershell Community-Extensions voraussetzt.

Mit dem SQL-Server Agent und der Datenbankrolle ""SQLAgentUserRole"" in der msdb-Datenbank kann man einem SQL-Login Zugriff auf einen Job geben. Voraussetzung ist, dass der Login dem JOB auch als Owner zugewiesen wird. Soll der User allerdings auch die Zeitpläne für geplante Aufträge verwalten, stellt man fest, dass dies nicht unbedingt klappt. Ursache dafür ist die schlecht Dokumentierte Tatsache, dass der Login auch Besitzer der Zeitpläne sein muß. Hat er diese nicht angelegt, kann er dementsprechend keine Änderungen durchführen. Stattdessen bekommt er eine Meldung "The specified schedule @schedule_id() does not exist". Den Besitzer des Zeitplans kann man nur über die Tabelle msdb.dbo.sysschedules in der Spalte owner_sid einsehen. Das folgende Script zeigt alle Job an, bei denen Besitzer für Zeitplan und Job nicht identisch sind:

SELECT (SELECT name FROM sys.server_principals WHERE [SID] = ss.owner_sid) AS ScheduleOwner,
 (SELECT name FROM sys.server_principals WHERE [SID] = sj.owner_sid) AS JobOwner,
 ss.name AS ScheduleName, 
 ss.owner_sid AS ScheduleOwnerSid, 
 sj.name AS JobName, 
 sj.owner_sid AS JobOwnerSID
FROM msdb.dbo.sysschedules AS ss
INNER JOIN msdb.dbo.sysjobschedules AS sjs
 ON sjs.schedule_id = ss.schedule_id
INNER JOIN msdb.dbo.sysjobs AS sj
 ON sjs.job_id = sj.job_id
WHERE ss.owner_sid <> sj.owner_sid

Und mit folgendem Script beheben Sie das Problem, indem Sie den Besitzer aller zeitpläne auf den gleichen Besitzer setzen wie den zugehörigen Job. Um nicht alle Jobs ungesehen zu überschreiben, geben Sie in der 1. Zeile einen Login-Namen ein:

DECLARE @JobOwner NVARCHAR(255) = 'Benutzer'
DECLARE @JobOwnerSid VARBINARY(85)
SELECT @JobOwnerSid = [sid] FROM master.sys.server_principals WHERE name = @JobOwner
UPDATE SS
SET ss.owner_sid = sj.owner_sid
FROM msdb.dbo.sysschedules AS ss
INNER JOIN msdb.dbo.sysjobschedules AS sjs
ON sjs.schedule_id = ss.schedule_id
INNER JOIN msdb.dbo.sysjobs AS sj
ON sjs.job_id = sj.job_id
WHERE (ss.owner_sid <> sj.owner_sid)
AND (sj.owner_sid = @JobOwnerSid)

Windows 10 - bei mir hat sich diese Beziehung zu einer Haßliebe entwickelt. Ich bin wirklich inzwischen am Überlegen, ob ich nicht doch lieber einmal Linux probieren sollte. Auch nach einem Jahr habe ich nicht das Gefühl, dass Windows 10 aus der Beta-Phase raus ist, und das, obwohl ich inzwischen (aus genau diesen Gründen) nicht mehr an der Insider-Preview teilnehme. 

Beispiel gefällig? Ich habe Stunden damit zugebracht herauszufinden, warum meine CPU-Last ständig oberhalb von 50% liegt. Ich habe jetzt die Ursache gefunden - sie tut es gar nicht. Der Taskmanager zeigt einfach nur völlig falsche Werte an. Auf die Idee bin ich gekommen, nachdem ich einen Artikel gefunden habe, der beschrieb, dass es im Taskmanager den Idle-Task nicht mehr gibt, und dass daher der Task-Manager Prozess manchmal sehr hohe Lastwerte anzeigt. Daraufhin habe ich den Sysinternals Process Monitor angeworfen und - während der Taskmanager konstant fast 50% Last anzeigte, dümpelte der Procmon bei 4% Last herum. 

Die beste Lösung für das Problem - Den Taskmanager gleich durch Procmon ersetzen. Dafür bring Procmon sogar eine eigene Funktionalität mit. Klicken Sie im Menü unter Options einfach auf "Replace Task Manager", und Procmon erledigt den Rest für Sie. Wählen Sie die Option erneut, stellt Procmon den Taskmanager wieder her. Und da es sich auch bei Procmon um ein Microsoft-Tool handelt, muß man sich auch keine weiteren Gedanken machen. Das besser Werkzeug ist der Procmon eh. 

Weiterführende Links: