Netz-Weise Logo

Weisheiten - der Netz-Weise Blog

Hier finden Sie Tipps und Tricks für vor, während und nach der Schulung.

Unix/MySQL Timestamp in Datumswerte mit Powershell umwandeln

In Unix und MySQL werden Datumswerte oft als Timestamps angegeben. Ein Timestamp ist eigentlich ein Datums/Zeitwerte, der aber als Integer gespeichert ist und die Sekunden ab dem 1.01.1970 angibt. Diese Zeitzählung wird auch als "Epoch date" bezeichnet.

Die Umwandlung in einen Datumswert in Powershell ist eigentlich recht einfach, da uns Powershell alle zur Umrechung notwendigen Funktionen zur Verfügung stellt. Das Datum des 1.1.1970 liefert uns get-Date:

Get-Date '1/1/1970'

Get-Date liefert ein Objekt vom Type Datetime zurück. Alle Objekte vom Typ Datetime besitzen eine Reihe von Methoden für die Datumsmanipulation. Wir benötigen hier die Methode AddSeconds() zum Aufaddieren von Sekunden:

$Timestamp = 1464257993
(Get-Date '1/1/1970').AddSeconds($Timestamp)

Weiterlesen

SQL-Server Fehleranalyse mit sp_blitz

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. 

Laufzeit der Gruppenrichtlinien-Ausführung bestimmen

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:

 

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?   

Office 365 - Email Weiterleitung einrichten

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

Office 365 Active Sync

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

Die SID-History, Token-Bloating und SID-History Cleanup

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/

Failover Cluster Manager - A weak event is created

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

Authentifizierungsdaten mit Powershell sicher speichern und wiederverwenden

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. 

Powershell-Script zu Exe(n)

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.

SQL-Server Agent-Jobs vom Entwickler bearbeiten lassen

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)

 

Markiert in: