Wer jetzt einen Ohrwurm hat, ist mindestens ein Kind der späten 1980er Jahre. 🙂 Bitte, gern geschehen. Für alle Anderen sei hier der Wortwitz erklärt.
Nach mehreren Jahren Ruhe reaktiviere ich also wieder mein Blog, nachdem tatsächlich viel passiert ist und ich wieder Lust verspüre mein Wissen, besser meine Erkenntnisse, zu teilen.
Ich habe vor in nächster Zeit eine lose Artikelreihe über folgende Themen zu schreiben:
Meine ersten Erfahrungen mit Docker (ja, früh‘ dran, ich weiß)
System Automatisierung mit Ansible und Windows (!)
IIS Konfiguration über Powershell (ja, der Windows Webserver)
Heute beginne ich damit, ein Pferd von hinten aufzuzäumen. Eigentlich beschäftige ich mich schon länger mit Hausautomation (November 2014 IIRC), habe aber noch nie einen Artikel in meinem Blog dazu verewigt. Aber heute ist es soweit. 🙂
Meine bisherige FHEM Installation läuft auf einem Raspberry Pi 2 unter Raspbian Wheezy, ist also Betriebssystem seitig nicht mehr ganz auf dem Stand der Zeit. Auf einem zweiten Raspberry habe ich daher das aktuelle Image von Raspbian Jessie Lite auf die SD-Karte geworfen und FHEM installiert. Nun kommt die FHEM Standardinstallation nach wie vor mit den klassischen SysV Startskripten daher, Rasbian/Debian Jessie setzt aber mittlerweile auf den systemd statt auf den klassischen SysV init. Nach der FHEM Installation wird FHEM zwar gestartet aber eben über das /etc/init.d/fhem Skript. Das wollte ich ändern und ich beschreibe hier, wie ich das tat.
Bei der gestrigen Microsoft Patchinstallation auf unseren Servern ist mir aufgefallen, dass Clients (egal ob PC oder Server) nach der Installation der Patches ihren Report an den WSUS-Server nicht loswerden konnten. Zunächst aufgefallen ist mir das, weil sich nach einem
wuauclt /reportnow
kein aktualisierter Status in der WSUS Adminkonsole für den eben aktualisierten Host sichtbar wurde. Auch nicht nach mehrmaligem ausführen des Befehls. Selbst der WSUS-Server sollte noch ein verfügbares Update haben, das OS zeigte mir aber keine verfügbaren Updates mehr an.
Also auf die Suche gemacht und prompt fündig geworden. Im WindowsUpdate.log fanden sich folgende Zeilen:
2016-07-26 08:35:05:892 884 1c3c Report Uploading 13 events using cached cookie, reporting URL = https://update.tld:8531/ReportingWebService/ReportingWebService.asmx
2016-07-26 08:35:05:939 884 1c3c PT WARNING: ReportEventBatch failure, error = 0x8024400E, soap client error = 7, soap error code = 400, HTTP status code = 200
2016-07-26 08:35:05:939 884 1c3c PT WARNING: SOAP Fault: 0x000190
2016-07-26 08:35:05:939 884 1c3c PT WARNING: faultstring:Die Anforderung konnte vom Server nicht verarbeitet werden. ---> Der Typeninitialisierer für "Microsoft.UpdateServices.Internal.Reporting.WebService" hat eine Ausnahme verursacht. ---> Netzwerkbezogener oder instanzspezifischer Fehler beim Herstellen einer Verbindung mit SQL Server. Der Server wurde nicht gefunden, oder auf ihn kann nicht zugegriffen werden. Überprüfen Sie, ob der Instanzname richtig ist und ob SQL Server Remoteverbindungen zulässt. (provider: SQL Network Interfaces, error: 26 - Fehler beim Bestimmen des angegebenen Servers/der angegebenen Instanz)
2016-07-26 08:35:05:939 884 1c3c PT WARNING: ErrorCode:(null)(0)
2016-07-26 08:35:05:939 884 1c3c PT WARNING: Message:(null)
2016-07-26 08:35:05:939 884 1c3c PT WARNING: Method:(null)
2016-07-26 08:35:05:939 884 1c3c PT WARNING: ID:(null)
2016-07-26 08:35:05:939 884 1c3c Report WARNING: Reporter failed to upload events with hr = 8024400e.
Heute möchte ich von einem seltsamen Verhalten berichten, für welches ich bisher noch keine Lösung gefunden habe. Gegeben sei ein Windows Server 2012 R2 mit installierten Remote Desktop Services, der als Sessionhost verwendet wird. Soweit so unspektakulär. Ein Anwender berichtete mir nun das er verschiedene Darstellungen des Remotedesktops bei Verwendung unterschiedlicher PCs (von denen die RDP-Session aufgebaut wird) hat.
PC A ist ein Windows 8.1 PC, welcher in der Firma steht und sein Hauptarbeitsgerät ist. An diesem PC sind 2 Monitore angeschlossen und die RDP-Sitzung verwendet beide Monitore. In der RDP-Sitzung verteilt der Anwender nun seine laufenden Anwendungen wahlweise auf den rechten oder den linken Bildschirm. Der linke Bildschirm ist als Hauptanzeige festgelegt. Die RDP-Sitzung wird nicht abgemeldet sondern schlicht geschlossen/ge-x-t. Bei einer erneuten Verbindung mit dem RD-Server kann er genau da weitermachen wo er aufgehört hat.
PC B ist ein Windows 10 PC, welcher im Homeoffice des Anwenders steht. An diesem PC sind ebenfalls 2 Monitore (identische Auflösung wie im Büro) angeschlossen und die RDP-Sitzung verwendet ebenfalls beide Monitore. Funktioniert auch, mit dem Haken, dass die Desktops vertauscht sind. Die in der RDP-Sitzung auf PC A rechts platzierten Anwendungen, werden hier links dargestellt und anders herum. Ebenfalls hat die Hauptanzeige vom linken Monitor auf den Rechten gewechselt.
Der Anwender berichtete außerdem, dass er explizit darauf geachtet hat, dass auf beiden PC der jeweils linke Monitor von Windows als Display 1 identifiziert und als Hauptanzeige verwendet wird.
Dieses Verhalten konnte ich unter Verwendung meines Notebooks (Win 10) und eines anderen PCs (Win 8.1) hier in der Firma reproduzieren. Zur Verdeutlichung mal 2 Bilder:
Windows 10
Windows 8.1
Abgesehen von den dargestellten Inhalten der Anwendungen, sieht man auf den Bildern auch schön wie die Hauptanzeige von links nach rechts wandert anhand der auf dem Desktop hinterlegten Icons.
Bisherige Suche nach möglichen Ursachen, bzw. Möglichkeiten zur Behebung waren noch nicht von Erfolg gekrönt. Es gibt massenhaft Berichte darüber, dass Multimonitor RDP-Sessions als solches nicht funktionieren, bezieht sich aber auf ältere bis sehr alte Windows Versionen. Wer Tipps und Hinweise hat darf sich gern in den Kommentaren verewigen!
Bisher waren Administratoren in Bezug auf die Upgrades von Windows 7 und 8 PCs auf das neue Windows 10 fein raus. Das lag daran, dass Microsoft das/die Updates mit dem berüchtigten GWX (Get Windows 10) Icon im Tray nicht über WSUS verteilte (oder ich eine Kombination Produkt/Klassifizierungen gefunden hatte, welche das verhinderte). Alle anderen Admins und Benutzer mussten sich immer wieder damit beschäftigen, weil Microsoft dieses Update KB3035583 jeden Monat wieder veröffentlicht und damit potentiell Gefahr läuft den Weg auf den PC zu finden. Das Problem hat man natürlich nur, wenn man Windows 10 nicht möchte.
Wer kennt das nicht? Man bekommt einen neuen PC auf den Tisch und muss ihn für eine/n neue/n Kollegen/in vorbereiten. Sofern man keine nackten PC’s ohne Betriebssystem kauft, kann da schon mal eine ganze Menge an Mist vorinstalliert sein. Früher beschränkte sich das auf das Ausmisten der vorinstallierten Programme über die Systemsteuerung. Seit Window 8 aber Metro Apps eingeführt hat, hat man hier unter Umständen auch einen ganzen Stall voll zu tun. Je nach Anzahl der vorinstallierten Apps dauert die ersten Anmeldung am PC für einen Benutzer schon mal ein paar Minuten und er kann sich dem tollen Farbwechselspiel von Windows hingeben.
Hallo! Ein paar Dinge müssen noch erledigt werden. Es dauert nicht lange. Oft aber doch.
Aber wie wird man diesen Wust von Apps jetzt los? App deinstallieren, na klar! Schließlich kann man auf der Startseite (Die Kachelseite bei Windows 8.x) oder im Startmenü (ab Windows 10) einen Rechtsklick auf die App machen und Deinstallieren auswählen.
In der Vergangenheit hat mir die Hyper-V Netzwerkkonfiguration immer wieder mal Kopfzerbrechen bereitet. Hier lauern so einige Fallstricke und deshalb möchte ich hier meine Erkenntnisse mit Euch teilen.
Bisher habe ich die Netzwerkkonfiguration immer über den Hyper-V Manager erledigt. Hier hat der geneigte Windows Administrator ein GUI vor sich, über welche er alle Dinge tun kann für die er sich berufen fühlt. Aber manches Mal irritieren die Hyper-V Manager Dialoge mehr, als dass es einem hilft. Über einen Rechtsklick auf einen Hyper-V-Server -> Manager für virtuelle Switches kann man die Konfiguration der virtuellen Netzwerkswitches einsehen, ändern und neue Switches erstellen. Und das sieht dann so aus:
Doch nur, welche der aufgelisteten Netzwerkkarten ist jetzt welche? In ordentlichen Servern sind die NICs, gerade wenn mehrere vorhanden sind, beschriftet oder nummeriert. Bei meinem Beispiel von 1 – 4, da eben richtigerweise 4 Netzwerkschnittstellen im Server verbaut sind. Hyper-V Server nennt die jetzt aber anders, 54 -57. OK, dann muss ich Karten halt anhand der MAC-Adressen auseinander halten – doch halt! Der Hyper-V Manager für virtuelle Switches verrät mir die MAC-Adressen nicht. Eine echte Unterscheidung ist also über die GUI nicht möglich und eine Konfiguration nach der Methode „Versuch macht kluch“ käme zum Einsatz (und kommt es bestimmt auch oft).
Aber zum Glück hat uns Microsoft ja die PowerShell an die Hand gegeben und wie es der Zufall will, gibt es natürlich die passenden cmdlets dafür. Alles andere wäre auch schwer verwunderlich, gerade wenn man die kostenfreie Hyper-V Server Version nutzt, welche lediglich eine Core Installation darstellt. Also nicht mit RDP auf den Server und Klicki-Bunti (RPD geht trotzdem, aber das ist eine andere Geschichte und soll ein andermal erzählt werden).
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.