dataKEKS

Wäre auch zu einfach gewesen - ich setze logischerweise den Haken per SSL ignorieren und was sagt die Website? Connectivty Test successfull Werde mir wohl mal das IIS Log vom Exchange ansehen, was anderes fällt mir im nächsten Schritt gerade nicht ein

Was ich gerade noch getestet habe: Apple per O2 und Android per D1 können den Exchange hinter seiner Fritz!Box pingen und der Zugriff auf den OWA funktioniert, also hängt es meiner Meinung nach nicht an DNS oder Portweiterleitung. Das mit dem Tool gehe ich gleich noch an und poste dann.

Hallo Kollegen! Irgendwie setzt mir die Sommergrippe zu - ich bin zu doof nen Exchange 2016 so einzurichten so das er nicht nur intern per Outlook funktioniert sondern auch per Handy. Es ist ein Exchange der von extern per 443 errecihbar ist und so wie sonst auch und mit einem selbst erstellten versehen das sowohl auf seinen internen FQDN als auch auf mail.domain.com lautet. Das CA Zertifikat habe ich schon auf den Handys eingebunden aber per Apple noch Android haben Lust sich zu synchronisieren :-( Wo würdet ihr als erstes Suchen wenn der OWA von extern funktioniert? Gruß Norbert

Hallo Kollegen! Leider haben wir noch einige Netze mit WSUS auf Server 2008 R2 Basis weswegen die Windows 10 Installationen im Build nicht aktualisiert werden ohne das man Hand anlegt. Da User ja auch gerne mal selber Hand anlegen war meine Idee die ein Skript per GPO beim Rechnerstart laufen zu lassen, dass die Windows Version samt Build auswertet und dann einfach per Mail Alarm schlägt wenn nicht die aktuelle Version installiert ist. Per wmic os get buildnumber bekomme ich die folgende Ausgabe auf einem 1511er Windows: BuildNumber 10586 Leider habe ich keine Idee ich darauf aufbauend weiter kommen könnte. Wie löst ihr diese Art von Problem? Grüße aus BaWü Norbert (der andere)

Hat denn wirklich keiner Idee woran es liegen kann wenn ein IIS als FTP nur Anmeldungen von Admins erlaubt, nicht aber normalen Benutzern?

Hey Nils! Hast ja Recht, aber das ist Kundenanforderung, es darf nix kosten und per VPN gesichert automatisiert nutzbar sein, da kommen Daten von verschiedenen Plattformen rein, daher FTP. Wie würdest Du den das Problem lösen? Sollte doch eigentlich jeden Techniker beim Ergeiz packen :-) Gruß Norbert

Guten Morgen Kollegen! Nach Nächten mit grauen Haaren und erfolglosem Suchen wende ich mich jetzt an euch (ich weiß, wie so erst jetzt?) mit meinem Problem. Bei einem Kunden sollten wir "mal kurz" noch einen FTP Server einrichten mit unterschiedlichen Rechten pro User, AD Integration und Benutzer die sich nicht gegenseitig sehen können. Also erst im Testnetz auf dem Laptop und dann im Produktivnetz einen Server mit ISS aufgesetzt und darauf aufbauen losgelegt. Problem? Nur auf dem Kundennetz, bei mir läuft es komplett. Wie wurde das ganze realisiert? Einrichtung FTP mit UserIsolation 1.) Windows Server installieren 2.) Windows Server mit fester IP versehen, in Domäne einbinden 3.) Windows Server mit IIS, Funktion FTP Server erweitern 4.) Per Kommandozeile md D:\inetpub\ftproot\%userdomain%\Admin 5.) Per Kommandozeile md D:\inetpub\ftproot\%userdomain%\Testuser 6.) Im IIS Manager FTP Site anlegen nach D:\Inetpub\ftproot ohne SSL, Beide Authentifizierungstypen, alle Benutzer bekommen Berechtigung lesen 7.) FTP Server Dienst (Microsoft-FTP-Dienst) zwingend neu starten 8.) Testlauf mit FTP Client und anonymer Anmeldung, es muss der Domänen Ordner sichtbar sein 9.) FTP-Benutzerisolation im IIS für die gesamte FTP Site aktivieren, globale Verzeichnisse deaktivieren 10.) erneuter Testlauf mit anonymer Anmeldung, diese muß jetzt fehlschlagen. 11.) Im IIS Manager auf der FTP Site unter FTP-Authentifizierung Anonyme Authentifizierung abschalten und unter den Eigenschaften von Standard Authentifizierung die Anmeldedomäne eintragen 12.) erneuer Testlauf, diesmal mit Anmeldung Admin / ESD (ohne Domäne), Upload darf nicht funktionieren 13.) Im IIS Manager auf der FTP Site unterhalb des Domänenordners bei FTP-Autorisierungsregeln für die Gruppe der Domänen-Admins Lese- und Schreibrechte erteilen 14.) erneuer Testlauf, diesmal mit Anmeldung Admin / ESD (ohne Domäne), Upload und Download muss funktionieren und im richtigen Ordner des IIS landen. MS Website: https://docs.microsoft.com/en-us/iis/publish/using-the-ftp-service/configuring-ftp-user-isolation-in-iis-7 Egal was ich mache, mit Domänenadmins funktioniert es, nur normale Benutzer nicht. In Filezilla bekomme ich diese Meldungen: Status: Verbinde mit 192.168.101.80:21... Status: Verbindung hergestellt, warte auf Willkommensnachricht... Status: Unsicherer Server; er unterstützt kein FTP über TLS. Befehl: USER Test Antwort: 331 Password required Befehl: PASS ******* Antwort: 530 User cannot log in. Fehler: Kritischer Fehler: Herstellen der Verbindung zum Server fehlgeschlagen Wie bekomme ich das gelöst, wie sagt mir der IIS wieso ich micht nicht anmelden darf denn so deute ich die Meldung, es heißt ja nicht falsches Kennwort so wie ich das Protokoll deute. P.S.: Ich weiß das ich hier gerade ohne SSL arbeite was nur bei der internen Kommunikation der Fall ist, wenn der FTP von extern erreichbar wir erzwingen wir SSL, nur für die Tests habe ich das mittlerweile bewusst weggelassen um hier nicht noch weitere mögliche Probleme zu bekommen. Ratlose Grüße aus BaWü Norbert (der andere)

Mit Blick in das VBS Skript von Office 2016 und ein wenig Englisch habe ich die Abfrage dann doch noch verstanden und erfolgreich angepasst. Original: For Each objOS in GetObject("winmgmts:").InstancesOf("Win32_OperatingSystem") Ver = Split(objOS.Version, ".", -1, 1) ' Win2K3 If (Ver(0) = "5" And Ver(1) = "2" And (objOS.ProductType = 2 Or objOS.ProductType = 3)) Then 'Check for supported OS flavor intPosition = InStr(UCase(objOS.Caption),FlavorEnterprise) If intPosition = 0 Then intPosition = InStr(UCase(objOS.Caption),FlavorStandard) If intPosition = 0 Then intPosition = InStr(UCase(objOS.Caption),FlavorDataCenter) If intPosition <> 0 Then folder = "win2k3" : CheckSPP(objWMIService) : Exit For End If ' Win7 If (Ver(0) = "6" And Ver(1) = "1" And objOS.ProductType = 1) Then folder = "win7" Exit For End If ' Server2008R2 If (Ver(0) = "6" And Ver(1) = "1" And (objOS.ProductType = 2 Or objOS.ProductType = 3)) Then folder = "win7r2" Exit For End If Next Wie im Technet geschrieben muss man dann "nur noch" die Anfrage um neuere OS anpassen, ich habe das so realisiert: folder = "unknown" For Each objOS in GetObject("winmgmts:").InstancesOf("Win32_OperatingSystem") Ver = Split(objOS.Version, ".", -1, 1) ' Win2K3 If (Ver(0) = "5" And Ver(1) = "2" And (objOS.ProductType = 2 Or objOS.ProductType = 3)) Then 'Check for supported OS flavor intPosition = InStr(UCase(objOS.Caption),FlavorEnterprise) If intPosition = 0 Then intPosition = InStr(UCase(objOS.Caption),FlavorStandard) If intPosition = 0 Then intPosition = InStr(UCase(objOS.Caption),FlavorDataCenter) If intPosition <> 0 Then folder = "win2k3" : CheckSPP(objWMIService) : Exit For End If ' Win7 If (Ver(0) = "6" And Ver(1) = "1" And objOS.ProductType = 1) Then folder = "win7" Exit For End If ' Server2008R2 If (Ver(0) = "6" And Ver(1) = "1" And (objOS.ProductType = 2 Or objOS.ProductType = 3)) Then folder = "win7r2" Exit For End If 'future OS's If (CInt(Ver(0)) >= 10) Then folder = "win7r2" Exit For End If Next Damit kommt also rein dieser Teil dazu: 'future OS's If (CInt(Ver(0)) >= 10) Then folder = "win7r2" Exit For End If Next Jetzt gibt es einen Verweise für die neueren Betriebssysteme und der verweist einfach auch auf den Ordner win7r2, somit sind keine weiteren Anpassungen notwendig und die Installation funktioniert :-) Grüße Norbert 'future OS's If (CInt(Ver(0)) >= 10) Then folder = "win7r2" Exit For End If Next

Habt ihr das hinbekommen mit dem Office 2010 KMS auf Server 2016? Ich habe zwar die kms_host.vbs nur leider finde ich da die Zeile nicht die im Technet Beitrag angeführt wird :-( Ratlose Grüße Norbert

Leute, ihr glaubt es nicht! Wir haben wirklich alles richtig gemacht bei der Migration, die Quelle der Probleme lag leider wie so oft komplett wo anders... Auch wenn ich euch technisch leider nicht wirklich die Ursache erklären kann, die NTDS.dit auf dem Quellserver (das war mal ne Zweiserver Umgebung mit DC + MSX + + + auf der einen Maschine sowie ein TS) wurde mittlerweile eine sauber aufgeteilte Umgebung mit einem reinen Exchange Server, aber das ändert natürlich nichts mehr am Verhalten des alten Exchange. Ja, mit Eventlog prüfen in allen Unterbereichen hätte es mir auch früher auffallen können, ich wurde stutzig als mir der Quellserver in der Powershell noch Postfächer für die Datenbank angezeigt hat die schon migriert waren und so kam ich dann eben erst auf die Idee mal wieder ins Eventlog zu sehen... Fehlerbild waren diverse Fehlermeldungen, angefangen bei NTDS (696) NTDSA: Datenbank C:\Windows\NTDS\ntds.dit: Index DRA_USN_index von Tabelle datatable ist beschädigt (0). Noch detailierter wurde es hier: Dieses Ereignis enthält Reparaturvorgänge für das Ereignis "1084", das zuvor protokolliert wurde. Diese Meldung deutet auf ein bestimmtes Problem in Bezug auf die Konsistenz der Active Directory-Domänendienste-Datenbank für dieses Replikationsziel hin. Bei der Übernahme von Replikationsänderungen für das folgende Objekt ist ein Datenbankfehler aufgetreten. Die Datenbank enthält nicht erwartete Inhalte, die verhindern, dass die Änderung durchgeführt wird. Objekt: CN=Ruiter Tanja,OU=Lehrer,OU=Benutzer,.............. Objekt-GUID: 203ca1ec-0077-4aee-ba28-d3779e42b61a Quell-DC: db2753ff-5192-4b96-867e-c998ef49e18e._msdcs........... Benutzeraktion Weitere Informationen finden Sie im KB-Artikel 837932 unter "http://support.microsoft.com/?id=837932".Ein Teil der Reparaturvorgänge ist dort aufgelistet. 1. Stellen Sie sicher, dass genügend freier Speicherplatz auf den Volumes vorhanden ist, auf denen die Directory-Datenbank gehostet wird, und wiederholen Sie den Vorgang. Stellen Sie sicher, dass sich die physikalischen Laufwerke, auf denen NTDS.DIT und die Protokolldateien gehostet werden, nicht auf Laufwerke befinden, auf denen NTFS-Komprimierung aktiviert ist. Prüfen Sie, ob Antivirussoftware auf diese Volumes zugreift. 2. Es ist eventuell vorteilhaft, wenn der Sicherheitsbeschreibungspropagierer gezwungen wird, die Objektcontainerherkunft in der Datenbank erneut zu erstellen. Dies kann entsprechend den Anweisungen im KB-Artikel 251343 unter "http://support.microsoft.com/?id=251343"durchgeführt werden. 3. Das Problem kann ggf. auch beim übergeordneten Objekt auf diesem Domänencontroller auftreten. Verschieben Sie das Objekt auf dem Quell-DC zu einem anderen übergeordneten Objekt. 4. Wenn dieser Computer ein globaler Katalog ist und der Fehler in einer der schreibgeschützten Partitionen auftritt, sollten Sie den Computer als globalen Katalog über das Kontrollkästchen "Globaler Katalog" in der Anwendung "Standorte und Dienste" herabstufen. Wenn der Fehler auf einer Anwendungspartition auftritt, können Sie das Hosten der Anwendungspartition auf diesem Replikat beenden. Dies kann mit dem Befehl NTDSUTIL.EXE durchgeführt werden. 5. Beziehen die neueste Version von NTDSUTIL.EXE, indem Sie das neueste Service Pack für dieses Betriebssystem installieren. Stellen Sie sicher, dass das DSRM-Kennwort (Directory Services Restore Mode) bekannt ist, bevor Sie den DSRM-Modus starten. Setzen Sie es andernfalls zurück, bevor Sie das System neu starten. 6. Führen Sie unter einer NT-Eingabeaufforderung im DSRM den Befehl "NTDSUTIL files integrity" aus. Stufen Sie das Replikat herab und überprüfen Sie die Hardware, wenn eine Beschädigung gefunden wurde und andere Replikate vorhanden sind. Stellen Sie das System über eine Sicherung wieder her, und wiederholen Sie diese Verifizierung, wenn keine Replikate vorhanden sind. 7. Führen Sie eine Offlinedefragmentierung mit dem Befehl "NTDSUTIL files compact" aus. 8. Der Befehl "NTDSUTIL semantic database analysis" sollte ebenfalls ausgeführt werden. Wenn Fehler gefunden wurden, können diese mit der Funktion "go fixup" behoben werden. Dies sollte nicht mit der Datenbankwartungsfunktion "ESE repair", die in diesem Fall nicht verwendet werden sollte, verwechselt werden, da dies zu Datenverlust bei der Active Directory-Domänendienste-Datenbank führt. Wenn keine dieser Aktionen erfolgreich ist und der Replikationsfehler weiterhin auftritt, sollten Sie diesen Domänencontroller herab- und anschließend wieder heraufstufen. Zusätzliche Daten Primärer Fehlerwert: 8451 Der Replikationsvorgang ist auf einen Datenbankfehler gestoßen. Sekundärer Fehlerwert: -1414 JET_errSecondaryIndexCorrupted, Secondary index is corrupt. The database must be defragmented Die Lösung war trotz Bauchweh erstaunlich einfach: Server im Verzeichnisdienst Wiederherstellungsmodus starten, mit ESEUTIL die DB defragmentieren und nach einem Neustart und ein paar Minuten warten war das komplette Active Directory endlich wieder sauber und die Exchange Migration lief vollends sauber durch. Lange Suche - Kurze Lösung: AD Replikation bei Exchange Migrationen im Auge behalten!

Danke für den Hinweis, ist es mir doch mal durch die Lappen gerutscht... Sollte vielleicht mal wieder schlafen gehen wenn das endlich durch ist, mittlerweile steht er bei 45% und schnarcht.... Scheint auch so nicht zu funktionieren :-( Im Eventlog steht das: Quelle MSExchange Mailbox Replication Ereignis ID 1114 The Microsoft Exchange Mailbox Replication service was unable to save changes to request. Request: 'd57ea7c8-a40b-48a9-8a79-998ba1d2b6b0' (387303e1-b279-4d3a-b467-7b9178854506) Database: Mailbox Database LGS-MS-1 Error: Die Anforderung ist ungültig. Überprüfungsergebnis: "Orphaned". Überprüfungsmeldung: "Der Active Directory-Benutzer wird nicht verschoben.". Mal sehen was ich dazu finde, ein Get-MoveRequestStatistics -Identity reinhart.gronbach@ bringt DisplayName StatusDetail TotalMailboxSize TotalArchiveSize PercentComplete ----------- ------------ ---------------- ---------------- --------------- Gronbach Reinhart WaitingForJobPickup 19.51 GB (20,950,917,158 bytes) 77 Und danach gehts nicht weiter...

Echt seltsam, auch nach löschen des Batches war der Move per Get-MoveRequest sichtbar. habe ihn dann per Remove-MoveRequest -Identity reinhart.gronbach@.... gekillt, dann per New-MoveRequest -Identity reinhart.gronbach@.... -TargetDatabase "Mailbox Database LGS-MS-1" neu auf den Weg gebracht und aktuell zeigt mir ein Get-MoveRequestStatistics -Identity reinhart.gronbach@ das an: DisplayName StatusDetail TotalMailboxSize TotalArchiveSize PercentComplete ----------- ------------ ---------------- ---------------- --------------- Gronbach Reinhart CopyingMessages 19.51 GB (20,950,860,142 bytes) 30 Läuft aktuell gemittelt mit knapp 15 MBit/s, wollen wir hoffen das es sich nicht ewig zieht.... Wollen wir hoffen das er es so durch bekommt, dann wäre eins klar: Nicht nur öffentliche Ordner, auch Postfächer besser per Powershell umziehen....

Wird gemacht, halte den Job mal an und lege los IT hat definitiv was von Selbstgeißelung: Laut ECP ist der Migrationsbatch beendet, ein Get-MoveRequest kennt ihn noch: DisplayName Status TargetDatabase ----------- ------ -------------- Gronbach Reinhart InProgress Habe dann die Migrationsbatch auch noch gelöscht, gleiches Ergebnis. Was mich wundert: Es steht keine TargetDatabase in der Anzeige. MoveRequest per Powershell abbrechen und noch einmal direkt per PS starten? LG Norbert

Hey Norbert! Im ECP unter Empfänger / Migration und nicht über die Powershell. Gruß Norbert P.S.: Könnte gerade meinen ich schreibe mir selbst :-)

Mal was ganz neues - so noch nie gesehen: [PS] C:\Windows\system32>get-moverequest | get-moverequeststatistics Neue Sitzung für implizite Remotevorgänge des Befehls "Get-MoveRequest" wird erstellt... Die Anforderung konnte nicht geladen werden. Zum Lesen der verwaisten Anforderungsnachricht wurden nicht genügend Informationen bereitgestellt. + CategoryInfo : NotSpecified: (:) [Get-MoveRequestStatistics], NotEnoughInform...manentException + FullyQualifiedErrorId : [server=LGS-MS-1,RequestId=f9520a98-ec79-4864-8f47-887124d1962a,TimeStamp=09.08.2017 08: 36:49] [FailureCategory=Cmdlet-NotEnoughInformationToFindMoveRequestPermanentException] 22A359F9,Microsoft.Exchang e.Management.Migration.MailboxReplication.MoveRequest.GetMoveRequestStatistics + PSComputerName : lgs-ms-1 Also so wie ich das im Moment sehe habe ich eine faule Quelldatenbank / fehlerhafte Elemente im Posteingang an denen sich der Umzug festfährt. Wenn ich versuche mal den Posteingang etwas zu unterteilen nach Jahren hängt er sich schon bei den ältesten Mails auf, und dabei habe ich keine 500 Mails ausgewählt.... DB offline nehmen und Reperaturlauf durchziehen? Norbert

Meldungen gibt es - die gibt´s gar nicht (laut Google). Auf dem Zielserver konnte ich nach einigem Suchen das im Eventlog finden: Failed to update notification object for async operation 'ForestWideOrg\ae4c942f-46ca-4332-8530-9c1576610df6'. Error = Microsoft.Exchange.Data.DataSourceOperationException: Die Postfachverschiebung wird ausgeführt. Versuchen Sie es später erneut. ---> Microsoft.Exchange.WebServices.Data.ServiceResponseException: Die Postfachverschiebung wird ausgeführt. Versuchen Sie es später erneut. bei Microsoft.Exchange.WebServices.Data.ServiceResponse.InternalThrowIfNecessary() bei Microsoft.Exchange.WebServices.Data.MultiResponseServiceRequest`1.Execute() bei Microsoft.Exchange.WebServices.Data.ExchangeService.FindFolders(FolderId parentFolderId, SearchFilter searchFilter, FolderView view) bei Microsoft.Exchange.Data.Storage.Management.EwsStoreDataProvider.InvokeServiceCall[T](Func`1 callback) --- Ende der internen Ausnahmestapelüberwachung --- bei Microsoft.Exchange.Data.Storage.Management.EwsStoreDataProvider.InvokeServiceCall[T](Func`1 callback) bei Microsoft.Exchange.Data.Storage.Management.EwsStoreDataProvider.GetOrCreateFolderCore(String folderName, FolderId parentFolder, Func`1 creator) bei Microsoft.Exchange.Data.Storage.Management.AsyncOperationNotificationDataProvider.GetDefaultFolder() bei Microsoft.Exchange.Data.Storage.Management.EwsStoreDataProvider.get_DefaultFolder() bei Microsoft.Exchange.Data.Storage.Management.EwsStoreDataProvider.<>c__DisplayClass22`1.<InternalFindPaged>b__1a() bei Microsoft.Exchange.Data.Storage.Management.EwsStoreDataProvider.InvokeServiceCall[T](Func`1 callback) bei Microsoft.Exchange.Data.Storage.Management.EwsStoreDataProvider.<InternalFindPaged>d__28`1.MoveNext() bei System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable`1 source) bei Microsoft.Exchange.Data.Storage.Management.EwsStoreDataProvider.FindByAlternativeId[T](String alternativeId) bei Microsoft.Exchange.Data.Storage.Management.AsyncOperationNotificationDataProvider.FindByAlternativeId[T](String alternativeId) bei Microsoft.Exchange.Data.Storage.Management.AsyncOperationNotificationDataProvider.UpdateNotification(OrganizationId organizationId, String id, Nullable`1 status, Nullable`1 percentComplete, Nullable`1 message, Boolean throwOnError, IEnumerable`1 extendedAttributes) Kommt von MSExchange Mid-Tier Storage mit Event ID 10002. Im ECP hängt der Job weiterhin, es kommen nur noch neue Zeilen mit immer dem gleichen Inhalt dazu: 09.08.2017 07:22:35 [LGS-MS-1] Auftrag wird abgegeben. 09.08.2017 07:52:33 [LGS-MS-1] Auftrag wird abgegeben. 09.08.2017 08:08:28 [LGS-MS-1] Auftrag wird abgegeben. 09.08.2017 08:22:10 [LGS-MS-1] Auftrag wird abgegeben. 09.08.2017 08:34:55 [LGS-MS-1] Auftrag wird abgegeben. 09.08.2017 08:48:39 [LGS-MS-1] Auftrag wird abgegeben. 09.08.2017 09:02:16 [LGS-MS-1] Auftrag wird abgegeben. 09.08.2017 09:59:29 [LGS-MS-1] Auftrag wird abgegeben. 09.08.2017 10:14:46 [LGS-MS-1] Auftrag wird abgegeben. Sehe mir gerade mal das Postfach mit Outlook an und ja - es ist ein Alptraum: allein knapp 40.000 Mails im Posteingang, aber was soll ich sagen - er ist der Boss.....

Hallo Kollegen! Alles besser mit den neuen Versionen? Nicht immer, gerade haben wir mal wieder die Bescheerung: Mit Server 2008 R2 und Windows 7 Clients keine Probleme, jetzt wo die Clients in den Schulferien aber auf Windows 10 gedreht werden sollen fängt der Spaß an - das rote X aus XP Zeiten lässt sich mal wieder sehen. Wir merken es aktuell sowohl bei der Banking Software (Starmoney Business) als auch bei der Schulverwaltungssoftware (Atlantis). Beide Produkte sind seitens der Verwaltung zwingend gesetzt weswegen wir nur die Möglichkeit der Lösung haben. Dank WDS Server und Open Vertrag können wir mit den Betriebssystemen sowohl Client- als auch Serverseitig spielen wie wir wollen und konnten es dabei soweit eingrenzen das ein und der selbe Client mit Windows 7 Pro und aktuellen Updates stabil arbeitet, auf Windows 10 aber schmieren die Programme ab. Laut Herstellern kann das natürlich überhaupt nicht sein, die Praxis zeigt uns aber das es wohl doch ein Thema im Zusammenspiel mit Windows 10 ist. Jetzt habe ich vor ein paar Wochen gelesen das mit dem kommenden Windows 10 Build SMB Version 1 abgeschaltet werden soll was für mich soviel bedeutet das es mehrere Versionen gibt. Kann hier der Hase im Pfeffer liegen? Was mich wundert: Die Schulverwaltungssoftware Atlantis läuft gegen einen Sybase SQL, hier sollte eigentlich kein SMB im Spiel sein, oder doch? Bin ehrlich gesagt komplett ratlos da alle Ansätze sich widersprechen oder ins Leere führten, auch ein AutoDisconnect im LanManServer auf 0xFFFFFFFF als auch ein KeepConn mit 0xFFFF im LanmanWorkstation waren trotz Empfehlung nicht die Lösung, daher zurück zum Titel: Dem roten X! Anders als auf den Windows 7 Client taucht bei den Windows 10 Maschinen recht schnell das rote X bei nicht benutzen Laufwerken auf, kann das die Ursache der Probleme sein? Kennt jemand unsere Beobachtungen vom Wechsel von 7 auf 10 und hat vielleicht schon die Lösung parat? Grüße Norbert

Wenn ich lese HPE Server. Kennst Du den SPP? Support Pack ProLiant, der aktualisiert Dir die gesammelten Stände von Platten, Raid, Board usw. Der HPE Support setzt das meistens vorraus bei Supportanfragen, wenn die Kisten nicht aktuell sind können die manchmal zicken von wegen und "machen sie die Maschine erst mal aktuell...) Was ich halt daran richtig schön finde: Du musst nicht ewig alles einzeln suchen sondern bekommst das meiste so erschlagen, nur was halt seit Release des letzten SPP raus kam kann er halt noch nicht haben... Grüße Norbert Bin mir gerade nicht ganz sicher wie das Ding im Gen9 Bios genau heißt - ist ASR aus? Der Automatic System Recover lang einem manchmal ins System und rebootet obwohl es dem OS wunderbar geht, war beim ML350 G5 immer wieder mal mein Sorgenkind...

Hey Norbert! Auf Dich ist auch immer Verlass :-) Der BadItem Counter steht auf 10 Habe gerade noch einmal drauf gesehen, er sagt nach wie vor Auftrag wird abgegeben: 08.08.2017 15:19:57 [LGS-MS-1] Auftrag wird abgegeben. 08.08.2017 15:59:06 [LGS-MS-1] Auftrag wird abgegeben. 08.08.2017 16:12:28 [LGS-MS-1] Auftrag wird abgegeben. 08.08.2017 16:25:59 [LGS-MS-1] Auftrag wird abgegeben. 08.08.2017 16:44:01 [LGS-MS-1] Auftrag wird abgegeben. 08.08.2017 18:33:20 [LGS-MS-1] Auftrag wird abgegeben. 08.08.2017 18:45:59 [LGS-MS-1] Auftrag wird abgegeben. 08.08.2017 19:03:50 [LGS-MS-1] Auftrag wird abgegeben. Ist ein MSX 2016 CU6 auf Windows Server 2016, beides gegen vollsynchronisierten WSUS gepacht, die Partition vom MSX 2016 mit der Datenbank hat noch 403GB frei, also auch kein Platzproblem auf der Zieldatenbank Laut GUI / Webinterface wurden bislang 0 Elemente übersprungen :-( Auf dieses Thema hatte ich auch schon gehofft, aber da der Counter noch nicht mal auf eins steht... Grüße Norbert

So wie ich das bislang eingrenzen konnte kommt das wohl nur bei wirklich alten Postfächern vor die auch schon mal die eine oder andere Migration mitgemacht haben. Im aktuellen Fall waren es sechs von 83 Postfächern, und das waren alles Postfächer der ersten Stunde, laut AD Konto waren sie alle im Januar 2006 angelegt worden, also wirklich noch auf dem Exchange 2003.... Gruß Norbert

Hallo Kollegen! Wer kennt das nicht - man macht etwas immer wieder und trotzdem gibt es dann diese Momente in denen man(n) wie der sprichwörtliche Ochse vorm Berg steht? Ziehen gerade unsere Postfächer vom Exchange 2010 auf seinen Nachfolger, einen Exchange 2016. Dieser hat auch 82 von 83 Postfächern sauber migriert, nur das vom Boss macht Ärger. Ich hatte bei Exchange Migrationen den Fehler der nicht angepassten Postfach Kontingente, das kann ich aber hier ausschließen: Laut ECP hat das Postfach aktuell 19,5 GB auf dem Quellserver, die Zieldatenbank hat ein Warnlimit von 25GB, Sende und Empfangslimits gibt es nicht. Trotzdem will eben dieses eine Postfach nicht umziehen, ich poste hier mal den Bericht: ​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​08.08.2017 13:02:47 [LGS-MS-1] Für dieses Postfach wird von vornherein eine Ausführung der ISInteg-Reparatur eingerichtet, weil es ein großes Postfach ist. "Größe des primären Postfachs = 20936863080, Archivpostfachgröße = 0, Konfigurationsgrenzwert für große Postfächer = 10737418240" 08.08.2017 13:02:47 [LGS-MS-1] '': Verschiebungsanforderung erstellt. 08.08.2017 13:02:49 [LGS-MS-1] Der Microsoft Exchange-Postfachreplikationsdienst 'LGS-MS-1.lan.domain.info' (15.1.1034.26 caps:37FFFF) überprüft die Anforderung. 08.08.2017 13:02:49 [LGS-MS-1] Verbunden mit Zielpostfach 'd57ea7c8-a40b-48a9-8a79-998ba1d2b6b0 (Primär)', Datenbank 'Mailbox Database LGS-MS-1', Postfachserver 'LGS-MS-1.lan.domain.info' Version 15.1 (Build 1034.0). 08.08.2017 13:02:49 [LGS-MS-1] Der Synchronisierungsstatus für die Anforderung "73affc75-a10b-41ff-92b1-0fb73192ca00" ist null. 08.08.2017 13:02:49 [LGS-MS-1] Verbunden mit Quellpostfach 'd57ea7c8-a40b-48a9-8a79-998ba1d2b6b0 (Primär)', Datenbank 'Mailbox Database.LGS', Postfachserver 'LGS-NT-1.lan.domain.info' Version 14.3 (Build 351.0). 08.08.2017 13:02:49 [LGS-MS-1] Die Anforderungsverarbeitung wurde gestartet. 08.08.2017 13:02:49 [LGS-MS-1] Quellpostfachinformationen: Reguläre Elemente: 90923, 19.49 GB (20,928,548,857 bytes) Regulär gelöschte Elemente: 711, 7.929 MB (8,314,223 bytes) FAI-Elemente: 145, 0 B (0 bytes) Gelöschte FAI-Elemente: 0, 0 B (0 bytes) 08.08.2017 13:02:49 [LGS-MS-1] Der Synchronisierungsstatus für die Anforderung "d57ea7c8-a40b-48a9-8a79-998ba1d2b6b0" wurde wegen "CleanupOrphanedMailbox" gelöscht. 08.08.2017 13:02:49 [LGS-MS-1] Eine alte Kopie des Postfachs wurde aus der Zieldatenbank entfernt. Der Vorgang wird in 30 Sekunden wiederholt. 08.08.2017 13:03:24 [LGS-MS-1] Die Postfachsignatur wird für Postfach 'd57ea7c8-a40b-48a9-8a79-998ba1d2b6b0 (Primär)' nicht beibehalten. Outlook-Clients müssen für den Zugriff auf das verschobene Postfach neu gestartet werden. 08.08.2017 13:03:26 [LGS-MS-1] Phase: CreatingFolderHierarchy. Prozent abgeschlossen: 10. 08.08.2017 13:03:26 [LGS-MS-1] Die Ordnerhierarchie aus Postfach 'd57ea7c8-a40b-48a9-8a79-998ba1d2b6b0 (Primär)' wird initialisiert: 97 Ordner gesamt. 08.08.2017 13:03:26 [LGS-MS-1] Fortschritt bei der Ordnererstellung: 0 Ordner in Postfach 'd57ea7c8-a40b-48a9-8a79-998ba1d2b6b0 (Primär)' erstellt. 08.08.2017 13:03:31 [LGS-MS-1] Ordnerhierarchie für Postfach 'd57ea7c8-a40b-48a9-8a79-998ba1d2b6b0 (Primär)' initialisiert: 96 Ordner erstellt. 08.08.2017 13:03:31 [LGS-MS-1] Phase: CreatingFolderHierarchy. Prozent abgeschlossen: 10. 08.08.2017 13:03:31 [LGS-MS-1] Phase: CreatingInitialSyncCheckpoint. Prozent abgeschlossen: 15. 08.08.2017 13:03:31 [LGS-MS-1] Fortschritt für anfänglichen Synchronisierungsprüfpunkt: 0/97 Ordner verarbeitet. Gegenwärtig wird das Postfach 'd57ea7c8-a40b-48a9-8a79-998ba1d2b6b0 (Primär)' abgeschlossen. 08.08.2017 13:03:37 [LGS-MS-1] Anfänglicher Synchronisierungsprüfpunkt abgeschlossen: 89 Ordner verarbeitet. 08.08.2017 13:03:37 [LGS-MS-1] Phase: LoadingMessages. Prozent abgeschlossen: 20. 08.08.2017 13:03:37 [LGS-MS-1] Phase: LoadingMessages. Prozent abgeschlossen: 20. 08.08.2017 13:08:39 [LGS-MS-1] Phase: CopyingMessages. Prozent abgeschlossen: 26. 08.08.2017 13:08:39 [LGS-MS-1] Kopierstatus: Vorgang für 4104/91771 Nachrichten, 417.6 MB (437,910,967 bytes)/19.5 GB (20,936,957,097 bytes), 10/97 Ordner abgeschlossen. 08.08.2017 13:13:43 [LGS-MS-1] Phase: CopyingMessages. Prozent abgeschlossen: 28. 08.08.2017 13:13:43 [LGS-MS-1] Kopierstatus: Vorgang für 6903/91771 Nachrichten, 943.3 MB (989,085,295 bytes)/19.5 GB (20,936,957,097 bytes), 10/97 Ordner abgeschlossen. 08.08.2017 13:18:43 [LGS-MS-1] Phase: CopyingMessages. Prozent abgeschlossen: 29. 08.08.2017 13:18:43 [LGS-MS-1] Kopierstatus: Vorgang für 9786/91771 Nachrichten, 1.336 GB (1,434,860,155 bytes)/19.5 GB (20,936,957,097 bytes), 10/97 Ordner abgeschlossen. 08.08.2017 13:23:48 [LGS-MS-1] Phase: CopyingMessages. Prozent abgeschlossen: 31. 08.08.2017 13:23:48 [LGS-MS-1] Kopierstatus: Vorgang für 12768/91771 Nachrichten, 1.756 GB (1,885,964,684 bytes)/19.5 GB (20,936,957,097 bytes), 10/97 Ordner abgeschlossen. 08.08.2017 13:28:54 [LGS-MS-1] Phase: CopyingMessages. Prozent abgeschlossen: 33. 08.08.2017 13:28:54 [LGS-MS-1] Kopierstatus: Vorgang für 14800/91771 Nachrichten, 2.312 GB (2,482,565,908 bytes)/19.5 GB (20,936,957,097 bytes), 10/97 Ordner abgeschlossen. 08.08.2017 13:33:56 [LGS-MS-1] Phase: CopyingMessages. Prozent abgeschlossen: 35. 08.08.2017 13:33:56 [LGS-MS-1] Kopierstatus: Vorgang für 16896/91771 Nachrichten, 2.833 GB (3,042,262,207 bytes)/19.5 GB (20,936,957,097 bytes), 10/97 Ordner abgeschlossen. 08.08.2017 13:38:58 [LGS-MS-1] Phase: CopyingMessages. Prozent abgeschlossen: 37. 08.08.2017 13:38:58 [LGS-MS-1] Kopierstatus: Vorgang für 18691/91771 Nachrichten, 3.377 GB (3,625,727,408 bytes)/19.5 GB (20,936,957,097 bytes), 10/97 Ordner abgeschlossen. 08.08.2017 13:43:59 [LGS-MS-1] Phase: CopyingMessages. Prozent abgeschlossen: 38. 08.08.2017 13:43:59 [LGS-MS-1] Kopierstatus: Vorgang für 20918/91771 Nachrichten, 3.866 GB (4,150,650,394 bytes)/19.5 GB (20,936,957,097 bytes), 10/97 Ordner abgeschlossen. 08.08.2017 13:49:01 [LGS-MS-1] Phase: CopyingMessages. Prozent abgeschlossen: 40. 08.08.2017 13:49:01 [LGS-MS-1] Kopierstatus: Vorgang für 22728/91771 Nachrichten, 4.447 GB (4,775,390,345 bytes)/19.5 GB (20,936,957,097 bytes), 10/97 Ordner abgeschlossen. 08.08.2017 13:54:04 [LGS-MS-1] Phase: CopyingMessages. Prozent abgeschlossen: 43. 08.08.2017 13:54:04 [LGS-MS-1] Kopierstatus: Vorgang für 24209/91771 Nachrichten, 5.079 GB (5,453,539,415 bytes)/19.5 GB (20,936,957,097 bytes), 10/97 Ordner abgeschlossen. 08.08.2017 13:59:06 [LGS-MS-1] Phase: CopyingMessages. Prozent abgeschlossen: 45. 08.08.2017 13:59:06 [LGS-MS-1] Kopierstatus: Vorgang für 26293/91771 Nachrichten, 5.628 GB (6,042,671,731 bytes)/19.5 GB (20,936,957,097 bytes), 10/97 Ordner abgeschlossen. 08.08.2017 14:04:13 [LGS-MS-1] Phase: CopyingMessages. Prozent abgeschlossen: 47. 08.08.2017 14:04:13 [LGS-MS-1] Kopierstatus: Vorgang für 28045/91771 Nachrichten, 6.259 GB (6,720,499,392 bytes)/19.5 GB (20,936,957,097 bytes), 10/97 Ordner abgeschlossen. 08.08.2017 14:09:18 [LGS-MS-1] Phase: CopyingMessages. Prozent abgeschlossen: 49. 08.08.2017 14:09:18 [LGS-MS-1] Kopierstatus: Vorgang für 29820/91771 Nachrichten, 6.884 GB (7,391,992,877 bytes)/19.5 GB (20,936,957,097 bytes), 10/97 Ordner abgeschlossen. 08.08.2017 14:14:20 [LGS-MS-1] Phase: CopyingMessages. Prozent abgeschlossen: 51. 08.08.2017 14:14:20 [LGS-MS-1] Kopierstatus: Vorgang für 31691/91771 Nachrichten, 7.495 GB (8,048,141,951 bytes)/19.5 GB (20,936,957,097 bytes), 10/97 Ordner abgeschlossen. 08.08.2017 14:19:22 [LGS-MS-1] Phase: CopyingMessages. Prozent abgeschlossen: 54. 08.08.2017 14:19:22 [LGS-MS-1] Kopierstatus: Vorgang für 33422/91771 Nachrichten, 8.106 GB (8,703,597,205 bytes)/19.5 GB (20,936,957,097 bytes), 10/97 Ordner abgeschlossen. 08.08.2017 14:24:23 [LGS-MS-1] Phase: CopyingMessages. Prozent abgeschlossen: 56. 08.08.2017 14:24:23 [LGS-MS-1] Kopierstatus: Vorgang für 35231/91771 Nachrichten, 8.697 GB (9,338,430,466 bytes)/19.5 GB (20,936,957,097 bytes), 10/97 Ordner abgeschlossen. 08.08.2017 14:29:23 [LGS-MS-1] Phase: CopyingMessages. Prozent abgeschlossen: 58. 08.08.2017 14:29:23 [LGS-MS-1] Kopierstatus: Vorgang für 37190/91771 Nachrichten, 9.284 GB (9,968,756,902 bytes)/19.5 GB (20,936,957,097 bytes), 10/97 Ordner abgeschlossen. 08.08.2017 14:34:31 [LGS-MS-1] Phase: CopyingMessages. Prozent abgeschlossen: 59. 08.08.2017 14:34:31 [LGS-MS-1] Kopierstatus: Vorgang für 42519/91771 Nachrichten, 9.673 GB (10,386,606,521 bytes)/19.5 GB (20,936,929,686 bytes), 19/97 Ordner abgeschlossen. 08.08.2017 14:39:35 [LGS-MS-1] Phase: CopyingMessages. Prozent abgeschlossen: 60. 08.08.2017 14:39:35 [LGS-MS-1] Kopierstatus: Vorgang für 49561/91771 Nachrichten, 9.785 GB (10,506,555,572 bytes)/19.5 GB (20,936,923,269 bytes), 22/97 Ordner abgeschlossen. 08.08.2017 14:44:35 [LGS-MS-1] Phase: CopyingMessages. Prozent abgeschlossen: 62. 08.08.2017 14:44:35 [LGS-MS-1] Kopierstatus: Vorgang für 52065/91771 Nachrichten, 10.42 GB (11,192,546,330 bytes)/19.5 GB (20,936,923,269 bytes), 22/97 Ordner abgeschlossen. 08.08.2017 14:49:41 [LGS-MS-1] Phase: CopyingMessages. Prozent abgeschlossen: 65. 08.08.2017 14:49:41 [LGS-MS-1] Kopierstatus: Vorgang für 53828/91771 Nachrichten, 11.31 GB (12,143,043,185 bytes)/19.5 GB (20,936,923,269 bytes), 22/97 Ordner abgeschlossen. 08.08.2017 14:54:44 [LGS-MS-1] Phase: CopyingMessages. Prozent abgeschlossen: 68. 08.08.2017 14:54:44 [LGS-MS-1] Kopierstatus: Vorgang für 56401/91771 Nachrichten, 12 GB (12,885,240,497 bytes)/19.5 GB (20,936,923,269 bytes), 22/97 Ordner abgeschlossen. 08.08.2017 14:59:44 [LGS-MS-1] Phase: CopyingMessages. Prozent abgeschlossen: 70. 08.08.2017 14:59:44 [LGS-MS-1] Kopierstatus: Vorgang für 58574/91771 Nachrichten, 12.78 GB (13,722,863,239 bytes)/19.5 GB (20,936,923,269 bytes), 22/97 Ordner abgeschlossen. 08.08.2017 15:04:51 [LGS-MS-1] Phase: CopyingMessages. Prozent abgeschlossen: 72. 08.08.2017 15:04:51 [LGS-MS-1] Kopierstatus: Vorgang für 61518/91771 Nachrichten, 13.33 GB (14,314,565,578 bytes)/19.5 GB (20,936,923,269 bytes), 22/97 Ordner abgeschlossen. 08.08.2017 15:09:51 [LGS-MS-1] Phase: CopyingMessages. Prozent abgeschlossen: 74. 08.08.2017 15:09:51 [LGS-MS-1] Kopierstatus: Vorgang für 63687/91771 Nachrichten, 13.84 GB (14,860,412,677 bytes)/19.5 GB (20,936,923,269 bytes), 22/97 Ordner abgeschlossen. 08.08.2017 15:14:54 [LGS-MS-1] Phase: CopyingMessages. Prozent abgeschlossen: 76. 08.08.2017 15:14:54 [LGS-MS-1] Kopierstatus: Vorgang für 65370/91771 Nachrichten, 14.41 GB (15,468,001,954 bytes)/19.5 GB (20,936,923,269 bytes), 22/97 Ordner abgeschlossen. 08.08.2017 15:19:57 [LGS-MS-1] Phase: CopyingMessages. Prozent abgeschlossen: 78. 08.08.2017 15:19:57 [LGS-MS-1] Kopierstatus: Vorgang für 67111/91771 Nachrichten, 14.94 GB (16,036,349,965 bytes)/19.5 GB (20,936,923,269 bytes), 22/97 Ordner abgeschlossen. 08.08.2017 15:19:57 [LGS-MS-1] Anforderung kann nicht gespeichert werden. Fehler: RelinquishJobInvalidTransientException. 08.08.2017 15:19:57 [LGS-MS-1] Phase: CopyingMessages. Prozent abgeschlossen: 78. 08.08.2017 15:19:57 [LGS-MS-1] Kopierstatus: Vorgang für 67111/91771 Nachrichten, 14.94 GB (16,036,349,965 bytes)/19.5 GB (20,936,923,269 bytes), 22/97 Ordner abgeschlossen. 08.08.2017 15:19:57 [LGS-MS-1] Auftrag wird abgegeben. 08.08.2017 15:59:06 [LGS-MS-1] Auftrag wird abgegeben. 08.08.2017 16:12:28 [LGS-MS-1] Auftrag wird abgegeben. 08.08.2017 16:25:59 [LGS-MS-1] Auftrag wird abgegeben. 08.08.2017 16:44:01 [LGS-MS-1] Auftrag wird abgegeben. Könnt ihr euch erklären wieso er bei diesem einen Postfach mir einen Strich durch die Rechnung macht? Der Erste Anlauf lief einen Tag und blieb gefühlt auch stehen weswegen dieser leider abgebrochen wurde ohne dessen Bericht zu sichern, ich weiß nur das er über 24 Stunden lief ohne fertig zu werden.... Grüße Norbert

Hallo Nils, Hallo Norbert! War wirklich nur ein AD, kein Witz. Der Tip über die Powershell wie in Frank von der MSX FAQ gelistet hat war die Lösung. # Linked mailbox in usermailbox verwandeln [PS] C:\>set-user user1 -LinkedMasterAccount $null' Ich danke euch, war mal wieder mit Blindheit geschlagen :-) Gruß Norbert

Hallo Kollegen! Nachdem unser Exchange Server mit nunmehr sechs Jahren ja doch ein ordentliches Alter hat sitzen wir aktuell an der Ablösung. Er kommt ganz ursprünglich von 2003, wurde auf 2010 migriert und jetzt läuft im Moment der Umzug auf Exchange 2016. Dabei sind mir mehrere Postfächer aufgefallen die als Postfach nicht auf Benutzer sondern verknüpft stehen. Jetzt habe ich schon einiges gesucht und bin über verschiedene Ansätze gestolpert: - Postfach deaktivieren und neu verbinden - Set-Mailbox %Name% -Type Regular Am Liebsten wäre es mir ohne Deaktivierung aus zu kommen weswegen ich die Idee mit Typwechsel sympatisch finde, nur leider funktioniert das nicht, es erscheint der Fehler: Das Konvertieren des Postfachs "Benutzername" von Typ "LinkedMailbox" in Typ "UserMailbox" wird nicht unterstützt. Wie geht ihr sowas an? Da es ausgerechnet das Postfach vom Boss ist liegt mir das Thema gerade schwer im Magen.... Gruß Norbert

Hallo Kollegen! Nachdem ja immer mehr 2016er Server als VMs laufen stellt sich die Frage wann / wie man die Hypervisor auf den neuen Stand bringt. Denkbar sind ja zwei Ansätze wenn man replizierte Hyper-V hat: - Aufheben der Replikation, Server frisch installieren und nach Updates, Treibern usw in Replikation wieder einbinden - Inplace Update Wie würdet ihr das angehen? Es geht mir im aktuellen Fallen um unsere drei Hyper-V 2012 R2 die lizenztechnisch sowohl seitens OS als auch Datensicherung als auch Hardware (aktuelle HPE Maschinen) komplett sauber sind und keine Limitierungen haben. Gruß Norbert

Egal wie lange man EDV macht - man lernt täglich dazu... An einer Schule habe ich eine grausige Aufgabe bekommen die ich aktuell nicht lösen kann und von der ich vermutlich auch nur Teile kenne.... AD im Dezember 2007 auf Server 2003 Basis installiert, seitdem gesichert Wechsel auf 2* 2008 R2 als DC, von Beginn an mit Exchange etc. Durch wechselnde Admins und Ruheständler kann ich nur auf die mir zur Verfügung stehenden Infos aufsetzen und hoffe diese so vollständig wie möglich weiterzugeben: CA lief auf einem der beiden 2008 R2 DCs, stellte aber weder für Clients noch Memberserver Zertifikate aus, deshalb hat sie der Admin gelöscht (Rolle entfernt und DB aus Dateisystem gekillt) und auf einem 2016er Memberserver eine neue Unternehmens CA aufgesetzt hat. Diese soll sowohl für den Exchange als auch NPS / Radius WLAN etc genutzt werden. Stand jetzt (und da kam ich ins Spiel) gibt die CA nur keine Zertifikate raus, weder an die DCs (mittlerweile 2* 2008 R2 am Hauptstandort plus 2* 2012 R2 am zweiten) noch Clients bekommen Zertifikate ausgestellt, auch Computer bekommen trotz GPO zur automatischen Registrierung keine. Auf den Clients taucht in den Internet Optionen unter Inhalte / Zertifikate / Vertrauenswürdige Stammzertifizierungsstellen die neue CA auf, die alte erscheint nicht mehr. Auf Nachfrage habe ich noch raus bekommen das er die alte CA gemäß dieser Anleitung aus dem AD mit Hilfe der MMC Active Directory-Standorte und -Dienste gekillt hat: https://technet.microsoft.com/en-us/library/dn486797(v=ws.11).aspx# Dort taucht auch nur noch die neue CA auf, sonst nichts. Die MMC der Zertifizierungsstelle hat auch jede Menge Vorlagen inklusive Computer und Domänencontroller, nur leider bekomme ich keine Zertifikate ausgestellt und weiß mir gerade auch nicht zu helfen, es klappt auch keine manuelle Anforderung eines Computer Zertifikates mit Hilfe der MMC. Weiß jemand Rat?