testperson

Hi, wie installierst du denn das OS? Ich installiere mir i.d.R. ein Image händisch und nehme das dann einfach als Template und vervielfältige das oder ich nutze "Convert-WindowsImage" (GitHub - x0nn/Convert-WindowsImage: Creates a Windows VM for Hyper-V from a Windows-ISO) jeweils in Kombination mit einer unattend.xml. Zur Prüfung, ob das System fertig ist "in grob": VM Networkadapter auf IP Adresse prüfen Per PS Session versuchen eine Verbindung in die VM zu erstellen In der VM auf das prüfen, was ich erwarte Ggfs. wäre in dem Zusammenhang auch DSC (Desired State Configuration) ein möglicher Ansatz. Gruß Jan

Nach dem Erstellen der Regel hast du diese auch aktiviert? Ich habe das gerade bei mir getestet und es funktioniert. Ansonsten: New-TransportRule -Name "Block TLD" ` -FromAddressMatchesPatterns "\.it$" ` -RejectMessageReasonText "We don't want to get emails from your tld!" ` -StopRuleProcessing:$true ` -Mode Enforce ` -Enabled:$true Das tuts bei mir in einem Test. ;)

Aber diese KI Projekte werden doch die ultimative Frage auf die Antwort "42" errechnen: the answer to life, universe and everything (youtube.com) :)

Und um diese Grundsatzdiskussion zu vermeiden, hat der barmherzige Herr Microsoft Exchange online (only) bereitgestellt. ;)

Hi, bislang habe ich Webhook Konnektoren in Teams genutzt, um dort per PowerShell Nachrichten zu senden. Das geht leider aufs Ende zu. Jetzt gibt es "New-MgTeamChannelMessage", um Nachrichten in Kanäle zu senden. Interaktiv funktioniert das wunderbar. Erstelle ich mir in Entra ID eine Anwendung und gebe dieser die passenden Rechte, endet das leider in: Jetzt könnte ich das Team und den Kanal zwar im "migration state" erstellen und dauerhaft so benutzen, vermute aber, dass das nicht Nachhaltig sein wird. :) Hat hier jemand eine Idee, wie ich die Webhooks ablöse und per PowerShell weiterhin non-interactive Nachrichten in Teams Kanäle senden kann? Die ersten Websuchen verweisen auf das o.g. New-MgTeamChannelMessage oder eben auf Webhooks. Danke und Gruß Jan

Das kannst du hier finden: Change the Microsoft 365 Apps update channel for devices in your organization - Deploy Office | Microsoft Learn

Hi, generell wäre ich auf Terminalserver / VDI eher im Monthly Enterprise Channel (MEC) oder Semi Annual Enterprise Channel (SAEC) anstatt im Current Channel. Release notes for Monthly Enterprise Channel releases - Office release notes | Microsoft Learn Release notes for Semi-Annual Enterprise Channel releases - Office release notes | Microsoft Learn Gruß Jan

Korrekt bzw. normal. It's magic. ;) Danke für dir Rückmeldung und ein entspanntes Wochenende!

Hi, funktioniert "der Rest" vom AppLocker denn? Läuft auf dem Client der Dienst "AppIDSvc" / "Anwendungsidentität"? Die App-Paketregeln sind auch aktiviert und stehen auf "Erzwingen"? Findest du etwas im Eventlog (Microsoft-Windows-AppLocker/Packaged app-Execution)? Gruß Jan

Ich liebe das Bild: NICHTLUSTIG-Cartoon: KÄFIG (joscha.com) :)

Hi, häng eine Aufgabe zur Abmeldung an die Disconnect Events (Windows RDP-Related Event Logs: Identification, Tracking, and Investigation | Ponder The Bits). Gruß Jan

Hi, Citrix hat für die Virtual Apps & Desktops / DaaS noch folgenden CTX Artikel veröffentlicht: Windows Virtual Delivery Agent for CVAD and Citrix DaaS Security Bulletin CVE-2024-6151 Betroffen: Current Release (CR) Citrix Virtual Apps and Desktops versions before 2402 Long Term Service Release (LTSR) Citrix Virtual Apps and Desktops 1912 LTSR before CU9 Citrix Virtual Apps and Desktops 2203 LTSR before CU5 Für die Workspace App: Citrix Workspace app for Windows Security Bulletin CVE-2024-6286 Betroffen: Current Release (CR) Citrix Workspace app for Windows versions before 2403.1 Long Term Service Release (LTSR) Citrix Workspace app for Windows versions before 2402 LTSR HTH Jan

Das _sollte_ nicht so wild werden/sein. Die Netscaler IP befindet sich im Managment-Netz bzw. hat da nicht Hinz und Kunz Zugriff drauf. Und eine Subnet IP mit aktiviertem SNMP ist ja auch im Monitoring Netz. :)

Hi, leider ist scheinbar die Citrix Support Website unter dem Ansturm zusammgebrochen: https://support.citrix.com/article/CTX677944/netscaler-adc-and-netscaler-gateway-security-bulletin-for-cve20245491-and-cve20245492 Hier die E-Mail: Hier eine andere Seite, die es scheinbar geschafft hat, den Artikel bei Citrix abzurufen: Citrix Netscaler ADC e Gateway afflitti da una grave falla di DOS e Open Redirect (redhotcyber.com) Das Downloadcenter von Citrix ist immerhin online und die aktuelle Firmware kann geladen werden. HTH Jan

Moin, hast du denn überhaupt "etwas", das von "Azure" profitieren würde/könnte? Oder willst du stumpf VMs nach Azure schieben und dort betreiben? Wir haben hier bspw. vereinzelt Kunden, die den AVD bzw. Windows 365 Cloud PC nur als "Jump Host" nutzen und von dort diverse SaaS Lösungen im Browser, "M365" und bspw. DATEV aus der/unserer "Cloud" nutzen. Wenn du den Azure Virtual Desktop nutzen willst, wäre es evtl. ein anderer Ansatz, diesen lokal auf Azure Stack HCI zu betreiben. DATEV lässt sich problemlos in Azure VMs betreiben. Da musst du nur den Softwareschutz und die Absicherung der RZ-Kommunikation auf dem Schirm haben. Generell ist es aber sicherlich einfacher, sich die bestehenden DATEV Cloud- bzw. Hostinglösungen (DATEVasp, PARTNERasp, SmartIT) anzusehen (IT-Outsourcing mit DATEV). Gruß Jan

Du meinst diese Liste: Security guidelines for system services in Windows Server 2016 | Microsoft Learn Was aktuelleres und offizielles gibt es AFAIK nicht.

Hi, du ergänzt den SPF Record um die öffentliche IP / A Record und inkludierst das Relay somit in den SPF. Zusätzlich solltest du dir dann die Firewall angucken und SMTP entsprechend einschränken, sofern das noch nicht der Fall ist. Gruß Jan

Hi, "Der Absender" "Adresse entspricht einem dieser Textmuster" -> "\.diezublockendetld$" sollte klappen. Gruß Jan

(Bevor ich mir nur für diesen Zweck bzw. eine Hand voll interner "Webserver" eine PKI ans Bein binde, kann ich sehr gut mit self-signed leben. :) Alternativ halt passende Zertifikate kaufen oder einen Dienst à la Let's Encrypt implementieren.)

Option 1) Nimm das in Kauf (Das dürfte keine Stunde Arbeit sein) Option 2) Stell das Zertifikat doch für 2 Jahre aus ;) Option 3) Bediene dich bei einer vertrauenswürdigen öffentlichen Zertifizierungsstelle und kaufe ein Zertifikat

RODC -> Diebstahlschutz, falls die Hardware geklaut wird. Dann können "nur" die zwischengespeicherten Credentials attackiert werden.

Hi, err.exe 0x800b010f # for hex 0x800b010f / decimal -2146762481 CERT_E_CN_NO_MATCH winerror.h # The certificate's CN name does not match the passed value. # 1 matches found for "0x800b010f" Die Hosts in der DMZ werden ja irgendeinen DNS Server nutzen. Erstelle da eine passende Hostzone für den WSUS oder nimm notfalls die Hosts-Datei (und dokumentiere das!). Gruß Jan

Nein. (Es sei denn du stellst den physikalisch an einen unsicheren Ort.) Sollte der RODC das Kennwort für einen User nicht gecached haben, macht er ein Passthrough zu einem RWDC.

Hi, unterm Strich möchtest du "das Reden" - was nicht hilft - automatisieren? (Sofern benötigt: Hol dir Rückendeckung für dein Vorhaben) Informiere per Mail, dass ab dem 01.08 o.ä. Sitzungen mit x Stunden im Leerlauf werden getrennt Sitzungen mit y Stunden im Status getrennt werden abgemeldet Informiere die User zwei und / oder eine Woche(n) vorher Konfiguriere die kommunizierten Werte ;) Gruß Jan

Da ich es soeben auch brauchte und es nicht mehr direkt funktionierte: RegKeys wie im o.g. Artikel (obwohl Office in 32 Bit) für die User: HKCU\Software\Microsoft\Office\Outlook\Addins\TeamsAddin.FastConnect LoadBehavior REG_DWORD = 0x00000003 HKCU\Software\Microsoft\Office\Outlook\Addins\TeamsAddin.FastConnect Description REG_SZ = Microsoft Teams Meeting Add-in for Microsoft Office HKCU\Software\Microsoft\Office\Outlook\Addins\TeamsAddin.FastConnect FriendlyName REG_SZ = Microsoft Teams Meeting Add-in for Microsoft Office HKCU\Software\Microsoft\Office\16.0\Outlook\Resiliency\DoNotDisableAddinList TeamsAddin.FastConnect REG_DWORD = 0x00000001 "Rest aus dem Script": Powershell-Scripts/install-new-teams.ps1 at main · Koetzing/Powershell-Scripts · GitHub Nach der Installation des MSI Pakets den Ordner "%ProgramFiles(x86)%\Microsoft\TeamsMeetingAddin" nach "%ProgramFiles(x86)%\Microsoft\TeamsMeetingAdd-in" kopieren und bei der User Anmeldung regsvr32.exe /s /n /i:user "C:\Program Files (x86)\Microsoft\TeamsMeetingAdd-in\1.24.13006.0\x86\Microsoft.Teams.AddinLoader.dll" ausführen. (Wenn das Add-in in %localappdata% liegt, ist es momentan ebenfall im Ordner "TeamsMeetingAdd-in" und nicht mehr in "TeamsMeetingAddin".) Evtl. funktioniert es auch direkt, wenn man im Script Zeile 131, 136, 137, 139, 140 in "..\TeamsMeetingAdd-in\.." ändert. In Zeile 140 dann (bei Office 32 Bit) noch "..\x64\.." in "x86" ändern.