phatair

Hallo zusammen, wir haben bei uns folgendes Problem. Auf Windows 10 22H2 Clients mit Office Standard 2016 (aktueller Patch Stand) und .NET Framework 4.8 kann die Funktion "3D-Karte" nicht mehr genutzt werden. Hier erscheint eine Fehlermeldung, dass keine Kommunikation mit Bing Maps hergestellt werden kann. Die Lösung laut einem Technet Eintrag ist, dass man folgende RegKeys setzen muss. Das habe ich getestet und siehe da, danach funktioniert die Funktion auch wieder. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v2.0.50727] "SystemDefaultTlsVersions"=dword:00000001 "SchUseStrongCrypto"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319] "SystemDefaultTlsVersions"=dword:00000001 "SchUseStrongCrypto"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727] "SystemDefaultTlsVersions"=dword:00000001 "SchUseStrongCrypto"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319] "SystemDefaultTlsVersions"=dword:00000001 "SchUseStrongCrypto"=dword:00000001 Soweit ich das hier bei Microsoft verstehe, ist das ja nur die Aktivierung von TLS1.2 für .NET. https://learn.microsoft.com/en-us/dotnet/framework/network-programming/tls Kann man das problemlos aktivieren oder erzwingt man damit TLS1.2 und alle Apps die kein TLS1.2 können funktionieren dann nicht mehr? Das ist mir irgendwie nicht ganz klar. Ich hätte jetzt erwartet, dass dies bei Win 10 22H2 und .NET Framework 4.8 das standardmäßig aktiviert ist. Scheint aber wohl nicht der Fall zu sein. Vielen Dank.

Noch mal ein Update. Die App synchronisiert nun wieder. Was am Ende geholfen hat ist mir nicht ganz klar. Wir hatten dann die getrennte DB endgültig gelöscht, die App auf dem Gerät komplett deinstalliert und noch mal alle ActiveSync Geräte von dem Account gelöscht. Dann haben wir übers Wochenende gewartet und heute noch mal die App installiert und eingerichtet. Die "Quarantäne" Info Mail wurde am Handy nicht angezeigt. Wir haben das Gerät dann am Exchange freigegeben und nach dem einmal eine Mail von dem Handy verschickt wurde geht jetzt auch wieder der Sync. Vielleicht hilft es ja noch mal jemanden.

Falls jemand mal auf diesen Thread aufmerksam wird und auch eine Mailbox neu erstellen will. Beachtet, dass ihr diesen X500 Wert kopieren und der neuen Mailbox einfügen müsst. Sonst werden Mails intern nicht mehr zugestellt. Falls ihr den Wert nicht habt, da die Mailbox schon gelöscht wurde. Kann über dieses Script der X500 Wert für den neuen NDR erstellt werden. Der NDR steht in der Unzustellbar Mail von Outlook. https://www.frankysweb.de/quick-dirty-imceaex-strings-in-x500-konvertieren/ Kam jetzt mal kurz ins schwitzen

So - Mailbox ist gelöscht bzw ist im SoftDelete Zustand. Mit folgendem PS Befehl habe ich das geprüft: Get-MailboxDatabase | Get-MailboxStatistics | Where { $_.DisconnectReason -ne $null } | ft DisplayName,MailboxGuid,DisconnectDate,DisconnectReason Hier wird die Mailbox jetzt 2x gelistet, mit der identischen GUID. Einmal mit "SoftDeleted" und einmal mit "Disabled" in der DisconnectReason Spalte Ich bekomme es aber gerade nicht hin diese Mailbox jetzt dauerhaft zu löschen um nicht die 30 Tage abzuwarten. Kann mir hier jemand auf die Sprünge helfen. Der folgende Befehl hatte leider nicht geklappt und hat mir eine Fehlermeldung ausgegeben mit "Der Sitzungsserver ist "Busy" und "es wurden keine gültigen Sitzungen angegeben". Get-MailboxDatabase | Get-MailboxStatistics | Where {$_.DisconnectReason -ne $null} | ForEach {Remove-StoreMailbox -Database $_.database -Identity $_.MailboxGuid -MailboxState Disabled} Das Verhalten nach dem ich die Mailbox jetzt neu erstellt habe ist weiterhin skurril. Nach dem die Mailbox neu erstellt wurde, ich alle ActiveSync Geräte noch mal geprüft und das alte gelöscht hatte, haben wir die Outlook App wieder auf dem Handy installiert. Nach Eingabe aller notwendigen Infos hat diese sich auch verbunden und er hat eine Mail im Posteingang gesehen. Das war eine "ActiveSync Quarantäne Info vom Exchange" die aber schon mehr als 1 Stunde alt war und in der "alten und jetzt gelöschten Mailbox" schon längst gelöscht wurde. Ich habe irgendwie die Vermutung, dass hier in der "Cloud" bei MS irgendwas schief läuft und die Inbox gar nicht mit unserem Exchange mehr spricht. Wir haben aber keine MAilboxen im Exchange Online. Habe auch extra noch mal geprüft ob dort ausersehen was angelegt wurde. Wir hatten in der Vergangenheit schon mal das Phänomen, dass die Outlook App weiterhin den Exchange anfragt, obwohl die App schon lange deinstalliert ist. Beispiel: Ich habe die Outlook App bei meiner Frau auf dem Handy zum Test installiert und meine Mail Zugangsdaten eingegeben. Das Gerät wurde in die Exchange Quarantäne geschoben udn dort habe ich es nicht zugelassen sondern gelöscht. Den Account und die App habe ich dann auf dem Handy auch wieder gelöscht. Trotzdem kamen über 2-3 Tage weiterhin von dieser Outlook App Anfragen an den Exchange und sind in der Quarantäne gelandet. So als wäre der Zugriff bei MS irgendwo im Cache. Vielleicht ist das ein ähnliches Problem aktuell und irgendwas überschneidet sich da. Ich werde jetzt mal die Outlook App nochmal komplett löschen inkl Konto und dann übers Wochenende abwarten ob weiterhin von dem Gerät Anfragen an den Exchange kommen. Ein Spaß ist das mit der Cloud

Das hab ich normalerweise auf dem Schirm, hätte aber auch schief gehen können. Danke für den Hinweis Ich werde berichten ob das die neue Mailbox dann die Lösung war oder ich weiterhin auf der Suche bin.

Und noch ein kleiner Nachtrag. Verschiebt der Kollege im Outlook (Desktop) z.B. 10 aktuelle Mails in "Gesendete Objekte" und aktualisiert dann die Android Outlook App im Ordner "Gesendete Objekte" sieht er diese Mails nicht. Verschickt er dann aber über die Android Outlook App eine Mail (z.b. an sich selber) dann erscheinen die verschobenen mails im "Gesendete Objekte" Ordner auf dem Handy und auch die versendete Mail kommt in der Mailbox an. Erstellt er einen Unterordner im Posteingang, wird dieser auch in der Android App angezeigt, aber die Mails darin nicht. Es sieht für mich einfach so aus, als wäre da irgendwas im Posteingang "kaputt" und ich werde jetzt wohl die Mailbox löschen. Wir haben alle Mails und Kalendereinträge in eine PST exportiert. Ich weiß nicht mehr weiter und hoffe, dass die Aktion das Problem löst.

Ich weiß nicht wo die IIS Logs für das EAS liegen. Ich habe bisher die EAS Logs wie folgt erstellt (hoffe das war korrekt). Set-CASMailbox <mailbox> -ActiveSyncDebugLogging:$true Dann habe ich das Handy mehrmals synchronsieren lassen und dann folgenden Befehl ausgeführt Get-MobileDeviceStatistics -Mailbox <mailbox> -GetMailboxLog:$true -NotificationEmailAddresses "Empfänger Mail" Hier habe ich dann lange Logs bekommen. Ich muss das Log erstmal prüfen, ob hier irgendwelche sensiblen Infos stehen. Werde es dann mal hochladen. Es steht aber immer wieder folgendes drin. Das sieht für mich so aus, als wäre alles OK. RequestBody : <?xml version="1.0" encoding="utf-8" ?> <FolderSync xmlns="FolderHierarchy:"> <SyncKey>3</SyncKey> </FolderSync> AccessState : Allowed AccessStateReason : Individual ResponseHeader : HTTP/1.1 200 OK MS-Server-ActiveSync: 15.1 ResponseBody : <?xml version="1.0" encoding="utf-8" ?> <FolderSync xmlns="FolderHierarchy:"> <Status>1</Status> <SyncKey>3</SyncKey> <Changes> <Count>0</Count> </Changes> </FolderSync> ResponseTime : 03/08/2023 13:39:48 Ja genau, die Android Outlook App von Microsoft. Eine Einstellung in der App kann ich ausschließen. Da ich, wie schon geschrieben, die App komplett deinstalliert habe und der Fehler auch auf einem anderen Gerät auftritt, wenn ich dort den Exchange Account in die Outlook App hinzufüge. Der andere Account funktioniert einwandfrei. Wir haben schon alle MAils in eine PST verschoben. Kalendereinträge muss ich noch prüfen. Den Test Link werde ich mal probieren.

Das habe ich leider auch schon gemacht über Powershell. Remove-MobileDevice -Identity <GUID> Und danach noch folgenden Befehl um auch das gespeicherte "allowedDevice" zu löschen, da sonst das Gerät wieder automatisch zugelassen wird. Set-CASMailbox -Identity <Mail Adresse> -ActiveSyncAllowedDeviceIDs @{remove='<DeviceID>'} Danach wurde das Gerät wieder in Quarantäne geschoben und nach dem erneuten zulassen ist der Fehler immer noch vorhanden gewesen. Deshalb bin ich langsam mit meinem Latein am Ende :(

Leider sind keine Regeln vorhanden. Das komische ist ja auch, dass die Mails im Outlook (Desktop) und im OWA korrekt angezeigt werden. Nur in der Android App wird der Posteingang einfach nicht mehr synchronisiert seit dem 23.02.23. Da die App schon deinstalliert wurde und nach einer Neuinstallation immer noch der Fehler auftrat, muss es am Exchange liegen. Wir haben auch schon den Account auf einem anderen Handy in die Outlook App hinzugefügt - auch dort ist der Fehler vorhanden. Deshalb ist meine letzte Idee, die Mailbox zu löschen und neu zu erstellen. Hier sind nur die Bedenken was mit den Kalendereinträgen ist und ob noch andere Dinge an die Mailbox "gebunden" sind, die dann mit der neuen Mailbox vielleicht nicht mehr gehen.

Da ist leider alles ok. Ich habe gerade die Mailbox auch noch mal auf eine andere DB migriert. Auch das hat leider keine Änderung gebracht bzw. keine Fehler geschmissen. Hatte gehofft, dass dadurch vielleicht etwas gerade gezogen wird oder zumindest ein Fehler sichtbar wird. Meine letzte Idee ist nun, dass ich die bestehende Mailbox lösche und ihm eine neue erstelle. Mails haben wir gesichert bzw. auch noch mal zusätzlich jetzt in eine PST kopiert. Aber was mache ich mit den Kalendereinträgen, kann ich die auch einfach in eine PST kopieren und danach in die neue Mailbox zurückschieben? Gibt es noch andere Stolpersteine, wenn ich die Mailbox lösche und eine neue erstelle? Vielen Dank!

Hallo zusammen, wir betreiben bei uns einen Exchange 2016 CU23 mit dem Januar 23 Security Update. Der Exchange läuft im Hybrid Modus. Alle Mailboxen liegen onPrem und wir greifen per offizieller Outlook App auf die Mails zu. Seit ein paar Tagen gibt es aber bei einem User folgendes Problem. Die Mails in der Outlook App werden nur noch bis zum 23.02.2023 angezeigt. Gesendete Mails werden aktualisiert, wenn er über die Outlook App eine Mail versendet. Im OWA sowieso im Desktop Outlook ist alles aktuell. Die Outlook App wurde schon deinstalliert und neu installiert. Ebenso haben wir den Account auf einem anderen Handy in die Outlook App hinzugefügt. Auch dort tritt der gleiche Fehler auf. Auf dem gleichen Handy funktioniert der 2. Account aber problemlos. Auch haben wir schon alle Mails neuen Mails bis zum 23.02 gelöscht, da die Vermutung war, dass es mit einer Mail ein Problem gibt und diese irgendwie die Synchronisierung verhindert. Das hat alles leider nichts gebracht. Ein generelles Problem kann ich also ausschließen. Auch das es an dem Endgerät liegt. Habt ihr noch eine Idee was ich da machen kann? Kann man die Mailbox irgendwie prüfen bzw. gibt es Logs wo ich sehen kann, warum der Sync des Posteingangs nicht mehr funktioniert? Vielen Dank und Grüße.

Danke Nils für die schnelle Rückmeldung, dann belassen wir es bei der Instanz und wir packen die DBs dort mit rein. Gruß, Steffen

Hallo zusammen, vorab, ich bin kein MSSQL Admin und mein Wissen darüber hält sich in Grenzen. Der DB Server hostet nur kleine DBs und hat nicht viel zu tun. Wir haben bei uns einen MSSQL 2017 Standard laufen. Aktuell gibt es eine Instanz und in dieser liegen mehrere DBs. Nun benötigen wir für einige Admin Anwendungen eigene DBs. Ich hätte jetzt, damit es übersichtlicher ist, eine eigene Instanz erstellt um die Admin DBs von den "User" DBs zu separieren. Das wäre jetzt nur eine Bauchentscheidung und daher mal die Frage in die Runde - macht sowas Sinn bzw. ist es eher kontraproduktiv mehrere SQL Instanzen (2-3) auf einem Server laufen zu lassen? Oder ist das eher Geschmacksache und ein wirkliches richtig/falsch gibt es nicht, wenn man es mit der Anzahl der Instanzen nicht übertreibt. Laut MS sind Sie ja auf 50 begrenzt. Danke euch schon mal. Gruß, Steffen

Hi Martin, danke für deine Rückmeldung. Das heißt ihr habt die GPO Einstellung gesetzt und zusätzlich noch das ms-DS-SupportedEncryptionType Attribut geleert oder gefüllt? Bei uns ist aktuell auf 99% der Computerobjekte das ms-DS-SupportedEncryptionType Attribut schon gefüllt mit dem Wert 28 was RC4, AES128, AES256 bedeutet. Ich würde es jetzt also so verstehen, wenn im EventLog nichts weiter protokolliert wird, sind wir erstmal sauber konfiguriert bzw. haben keine Geräte im Netz die eine schwache Kerberosauthentifzierung verwenden. Oder sehe ich das falsch? Gruß, Steffen

Guten Morgen zusammen, ich habe eine Frage zu der Kerberos-Protokolländerungen die mit dem KB5021130 begonnen wurde. Wir haben eine AD mit Domänenfunktionsebene und Gesamtstrukturfunktionsebene die noch 2012R2 ist. Die DCs sind 2019er. Mit dem November Update wurde ja die Initial deplyoment phase gestartet und über die EventLogs kann man prüfen welche Anmeldungen betroffen sind. Nun ist es bei uns so, dass hier das vCenter auftaucht. Event Source NETLOGON Event ID 5840 Event Text The Netlogon service created a secure channel with a client with RC4. Dazu hat auch vmware einen KB Beitrag erstellt. Weitere Einträge erscheinen im Eventlog nicht. Nun habe ich mir mal das vCenter AD Objekt angeschaut und das Attribut ms-DS-SupportedEncryptionType ist leer. Mit einem Script habe ich dann erstmal alle Computer Objekte geprüft. Hier war folgendes zu sehen Folgende Fragen stellen sich mir nun, da mit dem November Update ja mehrere Änderungen am Kerberos und Netlogon Protokoll gemacht bzw. gestartet Bedeutet das Ergebnis vom Script, dass ich die 13 Geräte die keinen ms-DS-SupportedEncryptionType Eintrag haben prüfen muss? Aktuell meldet sich ja nur das vCenter im Eventlog da es eine RC4 Verbindung nutzt, ich würde es also so verstehen, dass die anderen 12 Computer Objekte, die kein ms-DS-SupportedEncryptionType Attribut gefüllt haben, keine Probleme bekommen. Muss das ms-DS-SupportedEncryptionType Attribut im Computer Objekt gesetzt werden oder sollte das Attribut leer sein? Wenn das Attribut leer ist, wie bzw. wo wird der Standard geregelt? Wird das über die GPO Einstellung "Network security: Configure encryption types allowed for Kerberos" geregelt? Kann man davon ausgehen, wenn die genannten Eventlog IDs aus den hier verlinkten Beiträgen keine Treffer zeigen, dass man dann erstmal keine Probleme bekommt bzw. weitere Schritte durchführen muss? Für Tipps wäre ich sehr dankbar. Grüße

Alles klar. Danke für den Hinweis und den Denkanstoß. Das heißt aber, um auf die ursprüngliche Frage zurückzukommen, dass die Zertifikate standardmäßige durch die CUs aktualisiert werden oder direkt übers Internet aktualisiert werden?

das wäre natürlich auch eine Idee. Aber mal eine blöde Frage, woher bekomme ich diese bzw. gibt es da eine Übersicht? Ich kann zwar in den ZertSpeicher schauen, aber das sind ja extrem viele Zertifikate und Kategorien und das ist doch recht komplex.

Hallo zusammen, ich habe mal eine kurze Frage zum Windows Zertifikatsspeicher und dessen Aktualisierung. Unsere Server haben alle keinen bzw. sehr eingeschränkten Internet Zugriff. Nun ist es ja so, dass der Zertifikatsspeicher auch aktualisiert werden muss, damit Root Zertifikate usw. aktualisiert werden. Wie funktioniert dieses Update. Erfolgt das über die Kumulativen Updates die man über den WSUS freigibt oder erfolgt dies immer direkt übers Internet? Das würde dann ja bedeuten, dass man bestimmte Microsoft IPs freigeben müsste, damit der Zertifikatsspeicher aktualisiert werden kann. Oder sehe ich das falsch? Vielen Dank im Voraus.

Stimmt, dass hatte ich falsch verstanden. Ich hatte es so verstanden, dass man Domänen Admin sein muss um das Objekt zu übernehmen. Aber es ist so, dass man es übernehmen kann, wenn der Objekt Ersteller ein Domänen Admin war.

Hallo zusammen, ich habe dazu im Board noch nichts gefunden und ich hoffe der Bereich hier ist der richtige. Günther Born hatte schon vor ein paar Tagen darüber berichtet, dass mit dem CU 10/22 die Sicherheitslücke CVE-2022-38042 geschlossen wurde. Dies hat zur Folge, dass sich beim Domain Join etwas ändert. MS hat dazu auch einen KB Artikel veröffentlich, blöderweise ist der aber im KB Artikel von dem CU 10/22 nicht vermerkt. https://support.microsoft.com/en-us/topic/kb5020276-netjoin-domain-join-hardening-changes-2b65a0f3-1f4c-42ef-ac0f-1caaf421baf8 Wenn das CU 10/22 installiert ist, ändert sich folgendes. Bisher konnte ein Client auch dann in die Domäne aufgenommen werden, wenn das Computer Objekt schon bestand. Der Account der für den Domain Join genutzt wurde musste nur die passenden Rechte haben. Diese hatte man ja meisten per Delegation auf die OU gesetzt. Ab dem CU 10/22 geht das nicht mehr. Wenn das Computer Objekt schon besteht kann nur noch ein Domänen Admin oder der damalige Ersteller des Computer Objekts den Domain Join durchführen. Bei uns werden Clients beim Imaging über einen Service Account in die Domäne aufgenommen. Nur bestimmte Accounts haben überhaupt das Recht Clients in die Domäne aufzunehmen. Würde nun ein Client aus der Domäne genommen werden (z.B. troubleshooting) und ein Client Admin würde versuchen den Client wieder aufzunehmen, würde das fehlschlagen. Er müsste das als Domain Admin machen (ist ein NoGo bei uns) oder den Service Account aus dem Imaging nehmen. Letzte Lösung wäre dann, er löscht das Computer Objekt und lässt es neu erstellen. Ich hoffe, ich habe hier nichts komplett falsch verstanden. Finde die Änderung ärgerlich, aber nicht so problematisch, da dieses Vorgehen bei uns äußert selten vorkommen wird. Aber MS hätte es meiner Meinung nach besser kommunizieren müssen. Ich hätte diese Info nirgends gefunden. Was meint ihr? hab ich da einen Denkfehler und wusstet ihr von der Änderung?

Ich denke das werden wir so machen. Gefällt mir gut die Idee und wir haben das Problem mit den SID Leichen nicht mehr. Vielen Dank an alle!

Ja, es muss aktuell überall gespart werden ;) Nein, mal ernsthaft. Der UPN/SamAccountName ist bei uns immer der Nachname, wenn dieser schon belegt ist gibt es bestimmte Reihenfolge wie der Account benannt wird. Nun war mein erster Gedanke, wenn wir die Accounts deaktivieren und "archivieren" blockiere ich damit ja eben mögliche neue Accounts, die den gleichen Namen tragen würden. Beispiel von Evgenij mit Frau Müller wurde ja schon genannt. Aber ich könnte ja Accounts umbenennen, wenn die Mitarbeiter das Unternehmen verlassen. Dann wird aus Müller eben Müller220922. Wenn ich das, wie auch Martin schreibt, im UPN/SamAccountName/usw. mache, kann ich ja wieder einen Account Müller erstellen. Die SID wird dadurch ja nicht verändert, oder verstehe ich das gerade falsch?

Oh, ok :) Also wir verwenden keine generischen Anmeldenamen und alle User zu archivieren ist nicht realisierbar. Ich denke mal, wir werden das vielleicht auf Admin Accounts begrenzen und diese Accounts dann "archivieren". Vielen Dank.

Danke Dir Evgenij. Da hatte ich einen Denkfehler und beim nochmaligen lesen ist es mir jetzt auch klar Das sagt es ja eben aus, dass die Security configuration dann erlaubt das LAPS Attribut zu lesen und nicht das Attribut msDS-CreatorSid. Es ist dann tatsächlich so, dass der entsprechende User dann als Owner eingetragen ist und auch direkt im Computerobjekt Berechtigungen hat. Eine Frage hätte ich jetzt aber doch noch - wenn die Admin Accounts dann im Server Objekt stehen, sollte man dann den Domain Join von Servern über einen dedizierten Service Account durchführen? Wenn der Admin jetzt das Unternehmen verlässt, würde der User ja irgendwann gelöscht und damit würden im Server Computerobjekt SID Leichen entstehen. Oder löscht ihr Admin Accounts gar nicht, sondern deaktiviert diese nur, wenn die nicht mehr benötigt werden?

Also wenn ich es jetzt nicht komplett falsch verstehe, kann der User der im msDS-CreatorSid steht das laps Kennwort auslesen. Deshalb prüfen wir das. Da jetzt nur admins enthalten sind und diese das laps Kennwort sowieso auslesen dürfen, halte ich es auch nicht für kritisch. Würde hier aber ein normaler User enthalten sein, da dieser z.b. einen computer in die Domäne aufnehmen durfte (da ms-DS-MachineAccountQuota nicht 0) könnte dieser user das laps Kennwort auslesen. So verstehe ich das zumindest. Auszug aus dem offiziellen laps Operation guide: