=BT=Viper

Ok, auch hier konnte ich die Lösung finden. Ich hatte eine Build aus dem falschen Kanal genommen. Die entsprechenden Build findet man hier: https://support.office.com/de-de/article/Versions-und-Buildnummern-der-Updatekanalversionen-ae942449-1fca-4484-898b-a933ea23def7?ui=de-DE&rs=de-DE&ad=DE ​Um das Problem zu beheben musste ich zurück auf Version 1711 (Build 8730.2127) der monatlichen Updates.

Naja, für mich war es das schon, hatte es bisher aber auch nicht nötig wissen wie Office sich aktualisiert. Dafür bleibt das Problem eine Never Ending Story! Nachdem es bei meinem Kollegen wunderbar funktioniert hat war ich guter Dinge. Jetzt bekomme ich aber an anderen Rechnern die Meldung "Das hat leider nicht geklappt." Fehlercode: 30125-27 (404) Oh mann....

Daran wird es vermutlich liegen. Habe jetzt aber auch die Lösung! Bei click2run Office Installationen werden die Updates nicht über den Windows Installer installiert, sondern Office macht das selbst. Hier kann man auch keine Updates deinstallieren, sondern muss auf die entsprechende Build zurückkehren. https://www.msoutlook.info/question/784 In meinem Fall sah das dann wie folgt aus: cd %programfiles%\Common Files\Microsoft Shared\ClickToRun\ officec2rclient.exe /update user updatetoversion=16.0.8201.2213

ich bin noch immer am rum suchen. Das Problem tritt an jedem Office 2016 auf. Was die Suche noch erschwert ist, dass in Win10 keinerlei Office Updates angezeigt werden.

Ja genau das ist das das oben genannte Security Update. Scheint aber nicht der Grund zu sein.

Seit ca. einer Woche zeigt sich auf Windows 10 Rechnern mit Office 2016 folgendes Verhalten: ​- Anhänge die per Drag & Drop in eine E-Mail gezogen werden, können nach dem Versenden nicht geöffnet werden. (Element nicht gefunden) ​- Elemente (DOC, PDF, usw.) die per Drag & Drop in einen Outlook Ordner oder auch Öffentlichen Ordner des Exchange geschoben werden zeigen auch das Verhalten von oben. Ich hatte KB4011626 im Verdacht, aber das ist nicht installiert. Es war zwar im WSUS genehmigt, wurde mir am Client aber nicht angezeigt. wusa.exe /uninstall /KB:4011626 meldete auch das Update sei nicht installiert. Am WSUS habe ich das Update trotzdem mal auf Entfernen gesetzt. Mit Office 2013 funktioniert es. Also ist naheliegend das irgend ein Update daran schuld ist. Hat noch jemand dieses Verhalten und evtl. eine Lösung?

Eine derartige Idee hatte ich auch eben. Jedoch kann ich die Datei die mir der Netsh Befehl exportiert nicht effektiv bearbeiten. Liste Exportieren oder Backup bringt hier auch nix. Momentan versuche ich den DHCP auf einen 2012 R2 umzuziehen. mit Export-DHCP wird wohl ein XML erstellt. Ich hoffe da hab ich mehr Glück.

Da ich den IP Bereich erweitern muss, ist es notwendig die Subnetzmaske am DHCP für den bestehenden Bereich zu ändern. Leider ist das Feld ausgegraut. Die Änderung wäre aber notwendig da z.B. Drucker aus diesem Bereich ihre IP bekommen und aus dem neuen Bereich auch gedruckt werden soll. ​Gibt es eine Möglichkeit die Subnetzmaske zu ändern? Wenn ich den Bereich lösche müsste ich bestehende Ausschlüsse und Reservierungen komplett neu rein hacken... von den momentan vergebenen Adressen will ich mal garnicht reden. Der DHCP läuft auf einem Server 2008 R2.

Ziel: Ein in die Jahre gekommener Server soll ersetzt werden. Aufgrund versch. Anwendungen soll die IP, Name des Servers und die Domäne gleich bleiben. Prinzipiell kann ich das ganz stupide machen: Den neuen Server komplett frisch mit AD aufsetzen, Daten übernehmen und alle Clients neu in die Domäne aufnehmen. Wenn ich dann noch die lokalen User Profile mit Easytransfer migriere klappt das relativ problemlos. Eleganter wäre es natürlich, einen dritten Server einzusetzen, das AD dort hin zu migrieren, den alten Server aus der Domäne nehmen und den neuen Server hinzufügen, zum DC hochstufen und den Übergangsserver wieder aus AD raus nehmen. Ich frage mich jetzt nur ob das mit Foundation überhaupt möglich ist? Er muss ja alle Betriebsmasterrollen usw. haben. Oder gibt es noch einen dritten Weg? Also hier steht: https://technet.microsoft.com/en-us/jj679892(v=ws.11).aspx Must be the root domain controller in a domain that has no trusts at the root of the forest. This condition is temporarily allowed for migrations, but if persistent, the system will be forced to restart. Also sollte es ja funktionieren :thumb1: :)

Es sei denn man hat seinen WSUS im griff :P

Is nich wahr... sowas kann man machen?!?!?! :schreck: :jau: Bringt halt nix wenn man ca. 100 Clients in einem Unternehmen hat die noch mit 1511 installiert wurden bevor es 1607 gab :cool: (ichliebeklugsc***er)

Rechner die schon versucht haben das fehlerhafte Update zu installieren muss man leider mit der manuellen Installation fixen. Ein jungfreuliches Windows 10 konnte sich nun das 1607 und alle folgenden Updates über den WSUS ziehen. ;) Damit es mit 1607 klappt hier noch ein paar hilfreiche Links: https://support.microsoft.com/en-us/help/3159706/update-enables-esd-decryption-provision-in-wsus-in-windows-server-2012-and-windows-server-2012-r2 https://www.windows-faq.de/2016/08/24/windows-10-feature-updates-mit-wsus-verteilen-application-octet-stream/

Es ist 100% klar das der WSUS nix pusht... Danke für die Sackhaarspalterei!

Habt ihr einen Link dazu?

Der Weg das Update manuell oder per GPO zu installieren ist ja klar, dennoch wäre es ja wünschenswert das es über den WSUS sauber läuft. Momentan bin ich dabei das Ausrollen des 1607 über WSUS zu testen. Gehen wir mal von einem jungfräulichen Win 10 1607 aus. Der Client kommt ja merklich zum WSUS, sonst würde er ja die Updates garnicht anzeigen. Was fehlschlägt ist der Download da die Dateien Murks sind. Sobald diese Updates von MS ersetzt würden, müsste es wieder funktionieren. Natürlich nicht bei Win10 Rechnern die das Problem schon hatten. Da müsste dann mindestens der SoftwareDistribiution Ordner gelöscht werden.

Hi, gibt es hierzu mittlerweile Neuerungen? Wäre ja schon schön wenn es mit dem WSUS irgend wann funktioniert.

Super, genau das ist es. Danke!!! :thumb1:

Also wenn es ein Kollege ist würde ich ihn fragen ob er sonst keine Probleme hat. Meine Güte.... Ich frag mich wie oft es bei ihm vorkommt das er eine Mail ausdruckt und dann noch der Gegenüber ihn anmacht weil die Signatur fehlt. ​Die Mail wurde mit Signatur verschickt und ist somit konform. Wußte garnicht das ein Ausdruck auch konform sein muss :jau: Totaler Schwachsinn...

Exchange 2013: Per Transportregel werden bestimmte Mails an ein Moderator Postfach zur Genehmigung geleitet. Funktioniert soweit auch. ​Jedoch suche ich eine Möglichkeit die Ablaufzeit zu ändern. Diese ist momentan auf 2 Tage gesetzt, was dazu führt das Mails die freitags abgeschickt werden, montags abgelaufen sind weil sie nicht genehmigt wurden. ​Leider konnte ich dazu bisher garnichts finden. Jetzt setze ich meine Hoffnungen mal auf euch ;)

Wollte es auch gerade testen. Aber nachdem ich die Kommentare gelesen habe und Norbert es bestätigt lass ich das Update lieber auch runter vom System.

Ich darf vermelden das es nach den ersten 161 Updates dann funktioniert hat ;)

Die Targeteditionen passen natürlich und laut zig Artikeln im Netz muss es gehen. In einem Artikel ging es einem wie mir und einen Tag später hat es dann funktioniert. ​Na mal schaun was nach dem 171 Updates passiert...

Ich versuche mit DISM /online /Set-Edition:ServerStandard /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX /AcceptEula eine Testversion in eine Vollversion zu wandeln, bekomme aber immer folgende Meldung: Tool zur Imageverwaltung für die Bereitstellung Version: 6.3.9600.17031 Abbildversion: 6.3.9600.17031 Fehler: 87 Fehler: Es wurde versucht, ein Windows-Onlinebetriebssystem ohne Angabe eines gültigen Product Key zu aktualisieren. Führen Sie den Befehl erneut aus, und geben Sie einen gültigen Product Key an. Der Key ist ein OEM Key und vertippt hab ich mich natürlich auch nicht. Auch der KMS Key will nicht. Der Server läuft auf einem Hyper-V und wurde von der MS-Test ISO installiert und ist quasi jungfräulich. Ich lass jetzt mal alle Updates laufen. Vielleicht bringt das was. Hat sonst noch jemand eine Idee???

Zur Info, so hats funktioniert: Get-ADGroupMember [GRUPPE] -Recursive | Select -ExpandProperty objectGUID | %{Add-MailboxFolderPermission -Identity "$_ :\Kalender" -User [SMTP der Sicherheitsgruppe] -AccessRights Reviewer}

Das hatte ich natürlich zuerst versucht. Aber dann bringt er die selbe Meldung wie zuletzt.