dataKEKS

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?

ARG Ich glaub es nicht! Fehlersuche in der IT, eine Wissenschaft für sich! Norbert hat mich in die richtige Richtung geschoben durch seine verdeckten Hinweise Richtung Autodiscover. Nach Tagen der Grübelei und eben seinen Andeutungen habe ich wohl oder über mal das Tracing per Whireshark bemüht und was sahen meine müden Äuglein da: Der Client hat bei meinem User die direkte Kommunikation Richtung Exchange gesucht, nur bei den Sorgenkindern über einen Proxy??? Also in den GPOs gegraben und den Unterschied endlich gefunden: Die User die Probleme machen gehen über einen Proxy, die User die funktionieren..... Kleine Ursache - große Wirkung! Jetzt vergrabe ich mich mal in den GPOs und wie ich das beheben kann, die Proxy GPO kommt nämlich noch aus der Server 2003 Zeit und arbeitet im IE Voreinstellungsmodus weswegen ich sie nicht mehr bearbeiten kann....

Hallo Norbert! was neueres als Office habe ich leider nicht zur Verfügung. Du ziehlst vermutlich auf das ab was ich gerade nachreichen wollte: Autodiscover. Wenn ich ein per Outlook Anywhere eingerichtetes Profil starte ist der User verbunden und alle Ordner sind laut Outlook aktualisiert. Starte ich dann mit der rechten Maustaste und Klick aufs Outlook Icon im Systray die Option E-Mail-AutoKonfiguration testen geht es los mit "die automatische Konfiguration wurde gestartet. Dieser Vorgang kann bis zu eine Minute dauern. Ihre Einstellungen konnten nicht von der automatischen Konfiguration bestimmt werden. Im Protokoll sehe ich dann SMTP=User@xyz.de und er rasselt direkt auf IMAP und POP, Exchange sehe ich gar nicht. Teste ich auf der gleichen Maschine nur mit meinem User das gleiche Prozedere erscheint sofort: Die automatische Konfiguration wurde gestartet. Dieser Vorgang kann bis zu eine Minute dauern. Folgende Einstellungen wurden von der automatischen Konfiguration gefunden: Anzeigename: Norbert Dregger Interne URL für Outlook Web Access: https://serverfqdn/owa Externe URL für Outlook Web Access: https://mail.xyz.de/ Protokoll: Exchange-HTTP Server: serverfqdn Anmeldename SSL: Ja Gegenseitige Authentifizierung: Ja usw Kann das Autodiscover userabhängig laufen??? Sehe den Wald vielleicht vor lauter Bäumen nicht?

Sorry wenn es zu schwammig war, mir sind bislang drei Sachen aufgefallen: - Outlook 2010 lässt sich bei manchen Usern nur einrichten wenn man die Option für Outlook per HTTPs benutzt. Richtet man zum Beispiel ein neues Profil so kommt direkt die automatische Vervollständigung der E-Mail Adresse, im nächsten Dialog werden die ersten beiden Haken gesetzt (Netzwerkverbindung herstellen und Suche nach user@xyz.de Servereinstellungen) nur beim letzten Punkt - Am Server anmelden - erscheint eben bei manchen Usern die folgende Fehlermeldung: Die Aktion kann nicht abgeschlossen werden. Es besteht keine Verbindung mit Microsoft Exchange. Outlook muss im Onlinemodus oder verbunden sein, um diesen Vorgang abzuschließen. Richtet man es händisch ein und nutzt nur den Servernamen (egal ob NETBIOS oder FQDN) geht es nicht, trägt man unter Erweitert bei der Option für Outlook Anywhere den Servernamen ein (per DNS Eintrag auch NAT Tricks erreichbar geht es) - Nutzen wir bei den problematischen Postfächern die Verbindung per Outlook Anywhere kommen wir zwar ans Postfach, nicht aber an die öffentlichen Ordner heran - Auch wenn es vermutlich nichts mit dem Problem zu tun hat will ich es noch der Vollständigkeit halber erwähnt haben: Wir hatten User die nach der Migration vom MSX 2010 auf den 2016 sich weder per OWA noch per Outlook anmelden konnten. Ursache war soweit ich es eingrenzen konnte in jedem Fall das gleiche: Obwohl wir nur interne Postfächer haben waren es verknüpfte Postfächer. Diese habe ich per Powershell nach der Anleitung der MSXFAQ beheben können: https://www.msxfaq.de/exchange/migration/linkedmailbox.htm Norberts Vermutung muss ich mittlerweile leider bestätigen, ich habe auch User gefunden die ebenfalls einen alten legacyExchangeDN Eintrag haben aber sich dennoch mit Outlook verbinden können Nachdem es erst zu schwammig war noch ein paar Details: 2* 2012 R2 DC, die 2008er sollen raus 1* 2012 R2 mit MSX2016 5 Standorte mit VPNs verbunden Clients mit Windows 7 und Office 2010 Es gibt nur zwei Smartphones und keine wirklich externen Zugänge, daher ist der Exchange nicht per Autodiscover von außen erkennbar weswegen meiner Meinung nach Norberts Idee mit dem Remote Connectivity Analyzer leider ins Wasser fällt so ich ihn nicht komplett falsch verstanden habe. Habe ich noch etwas vergessen? Ich hoffe nicht Norbert mit schlechtem Gewissen

Hallo heuchler! Den 2010er Exchange konnte ich fast problemos deinstallieren, es lies sich nur leider trotz entfernen vom alten OAB die public folder db nicht löschen, da hat nur ADSIedit geholfen. Danach lies er sich dann komplett sauber deinstallieren. Worauf spielst Du mit schaue dir mal via ADSIedit die Server an? Du meinst das Attribut msExchHomeServerName? Da steht der neue Exchange drin, sonst finde ich im User nichts mit Verweis auf den Server. Was ich mittlerweile mit Sicherheit sagen: Postfach deaktivieren und neu verbinden hat leider auch nichts gebracht, ich merke es sowohl an den fehlenden öffentlichen Ordnern als auch das sich Outlook 2010 nur dann einrichten lässt wenn ich den Server per Outlook Anywhere angebe.

Hallo Kollegen! Nach einer Migration eines MSX von Version 2010 auf 2016 läuft fast alles sauber, wir haben nur mit manchen Postfächern Probleme die sich im OWA nicht zeigen, wohl aber beim Versuch sie per Outlook anzusprechen. Wir wissen das es ursprünglich ein AD mit Exchange 2003 war und seitdem hoch migriert wurde, zwischenzeitlich gab es mal einen kompletten Ausfall des "PDC" samt Exchange (war damals eine Maschine" als zwei Platten im RAID 5 gestorben sind. Rein nach meinem Bauchgefühl habe ich den Eindruck das hier noch der alte Exchange irgendwo durchscheint. Grund meiner Annahme ist die einzige mir bislang aufgefallene Gemeinsamkeit das User mit Problemen noch einen alten legacyExchangeDN haben, da steht nämlich was mit "Erste administrative Gruppe" drin und nicht "Exchange Administrative Group (FYDIBOHF23SPDLT)" was ja mit Exchange nach 2003 kam. Kann sich jemand mit meiner Erklärung vorstellen was ich für ein Problem habe und wie ich es lösen kann? Aktuell denke ich an die Option bei beendetem Transport Dienst die User zu deaktivieren und sowie Exchange 2016 sie als getrennte Postfächer erkannt (mit einem Testuser dauert es aktuell) neu zu verbinden in der Hoffnung so alle Werte korrigiert zu bekommen nachdem frisch angelegte Benutzer problemlos funktionieren, manche der alten aber nicht. Gibt es eine Alternative das per Powershell on the fly to beheben? Grüße aus BaWü Norbert Vielleicht noch zwei Nachträge: Es muss meiner Meinung nach mit den Benutzerkonten zusammen hängen weil andere User am gleichen Rechner funktionieren, damit scheiden für mich Autodiscover etc aus

Hey Sunny! Kein SFTP, das kann der IIS soweit ich es verstanden habe nicht, er kann "nur" FTP mit SSL https://serverfault.com/questions/648855/is-iis-sftp-natively-supported-by-windows-server-2012-r2 Gruß Norbert Leute!!! Ihr werdet es nicht glauben! Es ist wie so oft - richtig gemacht und funktioniert trotzdem erst mal nicht! Nach langem suchen (sitze seit heute Mittag an dem Thema) bin ich gerade über diesen Artikel gestolpert: http://grantcurell.com/2013/12/31/failed-to-retrieve-directory-listing-filezilla-connecting-to-iis-behind-nat/ Da steht etwas zum Haare raufen: Den FTP Dienst nicht im IIS neu starten sondern über die Dienstesteuerung, das ist NICHT das gleiche! Kaum machte ich es über services.msc..... Sollte also noch mal jemand suchen, es funktioniert jetzt sauber und ich kann SSL erzwingen womit Klartext der Geschichte angehört :-) Geschaffte aber glückliche Grüße Norbert

Hallo IT Kollegen! Nachdem der FTP Server von Windows schon ewig von mir genutzt wird soll nun auch hier das Thema Sicherheit mehr Gewichtung bekommen, daher will ich auf SSL umschwenken was intern auch sauber funktioniert. Als Beispiel hier mal die Anleitung von WinSCP Wie vermutlich die meisten von uns hat der Heimserver keine eigene public IP sondern steht hinter einem NAT Router und das ist ja nicht unbedingt der größte Freund des FTP... Korrigiert mich bitte wenn meine Annahmen falsch sind: - FTP erst einmal intern am Laufen haben - dann unter FTP Site bei FTP-Firewallunterstützung sowohl eine Port Range als auch die Public IP eintragen und mit Klick auf übernehmen bestätigen - Ports in der Windows Firewall freigegeben oder so wie ich TEMPORÄR zum Test nicht mehr blocken lassen - Neustart der FTP Site - Einrichtung Port Weiterleitungen für Port 21 und die Portrange die im IIS unter Firewallunterstützung definiert wurde als TCP Weiterleitungen im vorgeschalteten NAT Device (bei mir Bintec) eintragen Leider tut es dann nur bei mir nicht, ich kann mich erst gar nicht anmelden, ich komme aber zumindest auf dem IIS / FTP an: 220 Microsoft FTP Service 200 OPTS UTF8 command successful - UTF8 encoding now ON. Benutzer (xx.yy.zz:(none)): ESD 534 Policy requires SSL. Anmeldung fehlgeschlagen. Probiere ich es von extern mit FileZilla bekomme ich nur diese Meldungen: Status: Verbindung hergestellt, warte auf Willkommensnachricht... Status: Initialisiere TLS... Fehler: GnuTLS-Fehler -206 in gnutls_global_init: Failed to acquire random data. Fehler: TLS konnte nicht initialisiert werden. Fehler: Herstellen der Verbindung zum Server fehlgeschlagen Hat jemand eine schlaue Idee was ich vergessen habe? Gruß Norbert