Autoren-Archiv: weed

Aktivierung des ’sa‘ Benutzers auf SQL Server Express Edition

Veröffentlicht am von — 4 Kommentare ↓

Problem

Auf neuen SQL Express Edition Installationen ist der sa-Benutzer meist noch nicht aktiviert. Per Default ist nur die Windows-Authentifizierung eingeschaltet, was die Nutzugn des SQL-Benutzer ’sa‘ verhindert.

Lösung

Zuerst aktivert man im SQL-Server die ‚gemischte Authentifizierung‘.

So ändert man den Authentifizierungsmodus des SQL Server (SQL-Authentifizierung zulassen)

  1. Ausführen des SQL Management Studio „Als Administrator“
  2. Verbindung mit der Instanz herstellen (Windows-Authentifizierung)
  3. Im Objekt-Explorer ganz oben auf das Wurzelelement (die SQL-Server Instanz) mit der rechten Maustaste die Eigenschaften öffnen
  4. Link unter dem Punkt Sicherheit unter der Serverauthentifizierung den neuen gemischten Serverauthentifizierungsmodus auswählen und mit OK bestätigen
  5. SQL-Dienst neu starten (Im Objekt-Explorer mit der rechten Maustaste auf den Server ganz oben und dann auf Neu starten)

SA-Benutzer einschalten

An der SQL-Konsole, sofern man als Administrator vernbunde ist, reichen diese beiden schnellen Befehle:

ALTER LOGIN sa ENABLE ;  
GO  
ALTER LOGIN sa WITH PASSWORD = '123NEUES_SA_KENNWORT12343' ;  
GO

vCenter Update „“Error in method invocation Timeout happens while sending message to microservice“

Veröffentlicht am von — Keine Kommentare ↓

Problem

Die Aktualisierung des VMware vCenter Servers (VCSA) kann bei der Lizenzanzeige (EULA) nicht fortgesetzt werden. Nach einem Klick auf „Next“ landet man immer im selben Bildschirm, der die Fehlermeldung „Error in method invocation Timeout happens while sending message to microservice“ zeigt.

Zudem findet man in /var/log/vmware/applmgmt/applmgmt.log mehrere Meldung wie:

DEBUG:vmware.appliance.update.update_functions: Exception happens  while sending message to microservice: ConnectionRefusedError(111,  'Connection refused')

INFO:vmware.appliance.update.update_functions:Timeout happens  while sending message to microservice

ERROR:vmware.vapi.provider.local:Error in invoking  com.vmware.appliance.update.pending in precheck - Timeout happens while sending message to microservice

Lösung

Der Update-Micrososervice vergisst manchmal, sein PID-file zu entfernen. Das verhindert den korrekten neustart des Prozesses. Das lässt sich an der SSH-Konsole der VCSA (SSH öffnne, mit ’shell‘ eine Shell starten) aber schnell beheben.

Prüfen ob die PID noch da ist

 ls /var/run/vmware/applmgmt/update_microservice.pid

Wenn dem so ist, diese PID File entfernen

rm /var/run/vmware/applmgmt/update_microservice.pid

Danach läuft da sUpdate sofort fehlerfrei weiter.

IIS reverse Proyxy HTTP-Header setzen zeigt nur „Fehler 500“ Seiten

Veröffentlicht am von — 1 Kommentar ↓

Problem

Eine Webanwendung beötigt bestimmt Header aus dem IIS (URL-Rewrite) Revese-Proxy. Oft gesehene Kandidaten sind beispielsweise:

  • HTTP_X_FORWARDED_HOST
  • HTTP_X_FORWARDED_PROTO
  • HTTP_X_FORWARDED_FOR

Konfiguriert man das nur innerhalb der URL-Rewrite-Regel, ist die Site sofort mit einem Serverfehler 500 nicht mehr erreichbar. Kann der IIS etwa keine Header hinzufügen oder ersetzen?

Lösung

Die Servervariablen, oder auch HTTP-Header, müssen vorher im IIS, beispielsweise auf Serverebene oder Siteebene, definiert werden. Nicht-Definierte Servervariablen können durch Regeln im nachhinein nicht ge- oder ersetzt werden. Das ist aus Sicherheitsgründen ja auch sinnvoll, nur vielleicht etwas irritierend umgesetzt.

1. Servervariablen definieren

Beispiel: Links die höchste Ebene (<SERNAME>) auswählen und im rechten Fenster doppelt auf „URL Rewrite“ klicken. Das ist natürlich auch auf Site-Ebene möglich, wir definieren dieses Beispiel aber im Server, damit die Variablen für alle Sites des Server gelten können. Danach gibt es rechts in der „Action Pane“ einen Link „Servervariablen anzeigen …“

… und schlussendlich kann man dort über „Hinzufügen“ die Variablen die man nutzen oder ändern möchte hinzufügen. Der Titel der pane „Zulässige Servervariablen“ weist auch deutlich in die richtige Richtung. Was hier nicht definiert ist, ist Serverseitig nicht zulässig. Serverseitig, weil eine Anwendung selbst natürlich Header senden und setzen kann, wie sie das möchte.

2. Servervariablen setzen oder ersetzen

Danach kann man in jeder Rewrite-Regel besagte Variablen (=Header) setzen oder ersetzen, ohne das der Server über einen „Error 500“ stolpert.

Exchange Abwesenheitsbenachrichtigung (Out of office reply) nur an bekannte Absender zuslassen

Veröffentlicht am von — Keine Kommentare ↓

Problem

Exchange-Absenheitsbenachrichtigungen (Out of Office replys) sind traditionell ein schwerwiegender Punkt interessanter Diskussionen. Technisch simpel umgesetzt, birgt das Konzept viele Gefahren für schweren Mißbrauch (Amplification-Attack, Spam, Datenschutz, Überwachung, Einbruch …).

Ein oft eingesetzer Kompromiss ist der Versand nur an „bekannte“ Absender. Da dem Exchange aber nicht alle Absender „bekannt“ sind (Exchange kann nachvollziehbarerweise nicht in Echtzeit alle Kontakte in allen Mailboxen durchsuchen) muss das pro Mailbox passieren. Outlook sieht diese Möglichkeit sinnvollerweise auch (als Mailboxsetting) vor. Leider bleibt die Auswahl weiterhin dem „fehleranfälligen“ Benutzer überlassen.

Nur in Outlook: „Jeder außerhalb meiner Organisation“ ist weiterhin anwählbar

Lösung

Die die Einstellung Serverseitig, also pro Mailbox, definiert ist, hilft hier eine Gruppenrichtlinie (GPO) nicht weiter. Diese würde vielleicht Outlook betreffen, aber von OWA und allen anderen E-Mail-Clients ignoriert werden.

Da diese Einstellung aber Pro-Exchange-Mailbox gesetzt wird, kann man via Powershell die gesetzte Einstellung relativ einfach „korrigieren“. Wir haben dazu dieses Script erstellt, das nebenbei auch den „Powershell state: busy“ Fehler umgeht, der auftritt wenn man zu viele Requests an die Exchange-API gleichzeitig sendet (foreach statt einfach |set).

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://MEINSERVER.MEINFQDN/PowerShell/ -Authentication Kerberos
Import-PSSession $Session -AllowClobber
Import-Module ActiveDirectory -ErrorAction STOP

Function ChangeMailboxListWithExternalAudience {
    $MailboxListWithExternalAudience = Get-Mailbox | Get-MailboxAutoReplyConfiguration | where { ($_.AutoReplyState -eq "Enabled") -AND ($_.ExternalAudience -eq "All") }

    foreach ($eintrag in $MailboxListWithExternalAudience) { 
        Set-MailboxAutoReplyConfiguration $eintrag.Identity -ExternalAudience "Known"
    }
}

ChangeMailboxListWithExternalAudience

Das Script wird einfach regelmäßig via „Geplante Aufgaben“ ausgeführt und rediziert so die Angriffsfläche auf einen (relativ) kleinen zeitlichen Versatz.

Bein Einsatz des Scripts auf die ExecutionPolicy achten!

Taskmanager zeigt keine CPU-Last Graphen mehr an

Veröffentlicht am von — Keine Kommentare ↓

Problem

Der Windows Taskmanager zeigt keine CPU-Last Graphen mehr an. Es gibt zwar pro Kern eine Box, aber es wird keine Last (keine „Linie“) mehr angezeigt.

Die Graph-Anzeige bleibt leer (nicht wie hier im Bild)

Lösung

Sowohl der Windows Client (Windows 10) als auch Windows Server (2016/2019) scheinen Schwierigkeiten mit der Ermittlung der CPU-Last für den Taskmanager zu haben, wenn eine externe Lastverwaltung die Leistungsaufnahme der CPU regelt. Mit „extern“ sind hier Hardwareseitige Systeme wie das BIOS (EFI-Controller) gemeint.

In HP-Servern ist das schnell gefixt: Im BIOS einfach dem Betriebssystem die Kontrolle über die CPU-Performance/CPU-Last zurückgeben.

HPE ProLiant Server öffnen mit F9 ihr Bios, dort unter „Power Profiles“ den „HP Power Regulator“ abschalten und auf „OS Control Mode“ zurückstellen.

Negative Folgen wie eine Performanceänderung, andere Leistungsaufnahme oder instabile Systeme konnten wir nicht beobachten. Aber der Taskmanager funktioniert sofort wieder und liefert dem grapen schicke neue Werte.