dataKEKS

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

Vielleicht kannst Du uns noch mit ein paar Details versorgen. Server 2008 R2 als TS sehe ich, aber von was für Auflösungen und Farbtiefen reden? Je höher Auflösung und Farbtiefe sind.... Haben das gleiche Thema mit Excel Usern wenn sie mit 32 Zoll Schirmen von daheim aus arbeiten wollen bei FHD und mehr bei voller Farbtiefe etc... Wichtig ist natürlich auch immer mit welcher Art von Anwendungen, die Grafikengine kann nicht alles richtig klein rechnen, und wie ja schon gesagt - auch VDSL ist asynchron. Bei Idealwerten hat ne 25er VDSL 5MBit/s Upload, ne 50er VDSL 10MBit/s Upload und bei nem 100er VDSL 40MBit/s Upload. Wenn Du sagst es läuft bei Dir intern performant: Check mal Deinen Taskmanager oder noch besser gleich den Ressourcenmonitor. Da siehst Du nämlich nicht nur die LAN Last sondern auch welche LAN Last wo hin geht. Wenn sich die Client zum Beispiel während der TS Sitzung noch gleich via VPN beim WSUS Updates saugen oder oder oder oder siehst Du das mit Abstand am Besten im Ressourcenmonitor, der Taskmanager geht nicht genug ins Details. Grüße dataKEKS

Jetzt möchte ich das Thema noch einmal aufgreifen da wir gerade auch immer mehr 2016er Server aufsetzen und es das Verhalten auch schon beim 2012er Server so gab. Es gibt ja zwei Lösungsansätze: Dienste deaktivieren oder Ausnahmen im Servermanager definieren damit er nicht mehr meckert. Ich für meinen Teil habe Bauchweh mit deaktivieren denn wenn wir an Terminalserver und zum Beispiel Google Chrome mit seinem Update Dienst denken ist es ja der falsche Weg die Dienste zu deaktivieren damit der Server Manager ruhig ist, oder nicht? Wie handhabt ihr dieses Thema? Grüße aus der Schule dataKEKS

Sorry das ich so doof frage: Wenn ich aber doch gerade wirklich tausende Mails im Exchange verschiebe, wieso puffert er selbst dann nicht mehr im RAM wenn er doch noch 20GB frei hat? Oder genauer gefragt: Ist es so verrückt in die Richtung zu denken soll er doch den RAM nehmen den er dediziert rein für sich als Exchange hat? Der physikalische Server hat 256GB RAM, da tun die 32GB für den Exchange wirklich nicht weh, ich finde es halt schade wenn sie ungenutzt bleiben wenn ich doch merke das er bei der Menge an Mails schon grübelt (auch wegen der Virenscanner, schon klar). Eigentlich heißt es doch immer nicht geht über RAM.... Nur das sollte er doch auch nutzen!

Das ist ne virtuelle Maschine, Maschine ist ein HP Proliant ML350 G9 mit 10* 2TB SAS 7.2k bei 4GB Controller Cache. Hypervisor ist ein Windows Server 2012 R2, die Mailbox Database hat aktuell 42GB. Gruß Norbert