mr.schrotti

Moin, das hab ich ja alles auch schon ausprobiert. Die Clients weigern sich trotz dem das Upgrade zu installieren. Über die Setup.exe aus dem Windows 10 ISO klappt die Installation dagegen in den meisten Fällen.

Also ich hab beim WSUS immer das Problem das vielen Clients die Upgrades gar nicht angeboten werden.... Ich dachte da auch an Treiber, aber auch das aktualisieren hat daran nichts geändert. WSUS sagt Upgrade ist freigegeben und steht zur Installation an, Windows sagt das System ist auf dem aktuellen Stand....

Moin, wenn ich ein Windows 10 Feature Ugrade ausführen möchte, benötigt Windows scheinbar einen angemeldeten Benutzer damit das klappt (ansonsten hängt das Setup irgendwann). Gibt es irgendwelche Möglichkeiten das anders zu machen? Über ein PXE Boot? Windows PE? Aktuell wird ein lokaler Benutzer angelegt, automatisch angemeldet und dann die Setup.exe mit silent Parametern aufgerufen. Wie ich finde aber eine fehleranfällige Krücke, so etwas würde ich gern vermeiden. Die Microsoft Guides beziehen sich immer auf WSUS (sehr unzuverlässig....), SCCM (haben wir nicht) oder Online (kaum Monitoring, auch nicht sinnvoll bei über 500 Clients) Ich wäre Dankbar für Tips & Tricks wie man das optimieren könnte :) Gruß Tobias

Dann will ichs erst recht nicht

Mhhh bei mir fehlen halt unter Organisation => Freigabe die entsprechenden Optionen. Ich habe dort nur die Möglichkeit eine Verbindung zu einem Federated Gateway aufzubauen... Sowas hab ich nicht und da die Freigabe ohnehin nur für Interne Zwecke ist reicht es die iCALs auf der internen OWA Adresse freizugeben. Wobei scheinbar die alte Policy nun doch funktioniert, jedenfalls kann ich nun einen iCAL Link generieren bzw. nach extern per mail schicken....

Moin, wir sind dabei von Exchange 2010 auf Exchange 2016 zu migrieren. Die User & Öffentliche Ordner wurden schon alle erfolgreich übertragen. Lediglich ein paar Postfächer die für Kalender genutzt werden sind noch auf Exchange 2010. Unter 2010 habe ich eine Sharing Policy die es erlaubt diese Kalender per iCAL freizugeben (wir nutzen das nur Intern um damit den Kalender im Intranet darzustellen). Eine entsprechende Policy existiert in unserer Exchange Organisation also schon. Leider funktioniert die Freigabe über OWA 2016 nicht, die Option dazu fehlt einfach. Über das ECP habe ich auch keinen Zugriff auf die Policy, denn Exchange verlangt unter "Organisation => Freigabe" das ich eine Verbundvertrauensstellung einrichte... Alle Anleitungen beziehen sich leider auf EX2013 wo unter Organisation => Freigabe die entsprechende Policy erstellt & Angepasst werden kann. Gibt's da einen Trick? Gruß Tobias

Moin, ich konnte das nun reproduzieren. Allerdings wird nicht wie zuerst angenommen die E-Mail mit der imceax adresse verschickt, sondern sie wird übermittelt weil sie im CC steht. Wenn ein Kollege über seine Exchange E-Mail Adresse von Organisation A verschickt und eine Adresse von Organisation B anschreibt wird die Adresse durch die IMCEAX ersetzt. Den Outlook Adresscache haben wir schon mehrfach gelöscht, das hat die Probleme aber nicht behoben. Gruß Tobias

Das bringt auch nix, ich kann das auch immer wieder mit neuen Tasks reproduzieren. Es scheint an der Option "Last Day of Month" zu liegen. Hier scheint er +1 zu rechnen (oder mit ner falschen Zeitzone zu arbeiten) Stelle ich den Task auf 22:30 Uhr am letzten tag wird daraus 23:30 Uhr am letzten Tag Stelle ich den Task auf 23:30 Uhr am letzten Tag wird daraus 0:30 Uhr (was natürlich dann wegen +1h am 1. tag um 0:30 Uhr ist) Stelle ich den Task auf 23:30 Uhr am ersten Tag bleibt es wie geplant am 1. Tag um 23:30 Uhr. Hier stimmt die Planung also. Das Lustige ist das es variiert ob er wirklich in den nächsten Tag wechselt oder den Task zu früh ausführt.... Vielleicht kann das ja mal jemand auf nem anderen Server 2016 validieren :) Ich kanns auf jeden Fall auch auf anderen 2016er und 2012er Servern reproduzieren.... Egal ob Deutsches Windows oder Englisches Windows.... Es lief jedoch seit Jahren problemlos also irgendwas scheint da vor ein paar Monaten durcheinander geraten zu sein....

Moin, so von gestern auf heute ist es nicht gelaufen.... und der aktuelle Plan sagt: PS C:\Users\administrator.BS> Get-ScheduledTaskInfo Transfer LastRunTime : 28.02.2018 00:30:30 LastTaskResult : 0 NextRunTime : 01.04.2018 00:30:30 NumberOfMissedRuns : 1 TaskName : Transfer TaskPath : PSComputerName : Das ist natürlich auch wieder so absolut gar nicht die geplante Zeit (letzter Tag des Monats um 23:30 Uhr)......

Moin, nein Zeitzonen kann man da auch nicht angeben... und die Lokale Zeiteinstellungen sind natürlich auch schon kontrolliert. Außerdem ist der Taskplaner ja auch noch der Meinung das er diesen Monat den Task noch laufen lassen muss. Das macht das ganze extrem seltsam. Gruß Tobias

Moin, da steht definitiv nur eine zeit drin ;) Gruß Tobias

Moin, ich hab ein skurriles Problem auf unserem Windows Server 2016 Datenserver.... Wir haben einen geplanten Task der am letzten Tag eines Monats um 23:30 Uhr getriggert wird. Nun fällt uns seit Monaten auf das der Task 2x läuft und das am falschen Tag. Beispiel: Für diesen Monat ist der Task für den 28.2.2018 um 23:30 Uhr geplant (das steht auch im Taskplaner) Gelaufen ist der Task nun aber bereits am 27.2.2018 um 23:30 Uhr und ein weiteres mal am 28.2.2018 um 0:30 Uhr. Es ist auch nicht das erste mal diesen Monat aufgetreten sondern passiert jeden Monat. PS C:\Users\administrator.BS> Get-ScheduledTaskInfo Transfer LastRunTime : 28.02.2018 00:30:30 LastTaskResult : 0 NextRunTime : 28.02.2018 23:30:30 NumberOfMissedRuns : 0 TaskName : Transfer TaskPath : PSComputerName : Über die Powershell Ausgabe sieht man das auch ziemlich gut das der Task zu früh gelaufen ist .... Ist dieses Problem irgendjemanden ebenfalls schonmal aufgefallen ? Die Uhrzeit und Zeitzone ist natürlich korrekt auf dem Server ;) Der Task wird auch nicht per GPO konfiguriert. Gruß Tobias

Moin, wir haben die Situation das wir Kollegen haben die 2 Exchange Postfächer von verschiedenen Organisationen im Outlook eingebunden haben.... Dabei tritt mit einem Konto das Problem auf, das der Empfänger scheinbar eine Folgende Mailadresse sehen: IMCEAEX-_o=unternehmen-B+20stadt_ou=Exchange+20Administrative+20+28FYDIBOHF23SPDLT+29_cn=Recipients_cn=name+2nachname55066033@unternehmen-A.de In der Adresse kommt die Exchange Organisation von Unternehmen B vor und abgesendet wird mit der Mail Domain von Unternehmen A... das kann natürlich nicht funktionieren. Aber wieso passiert das? Ich kenne diese IMCEAEX Meldung nur von Verschiebungen von Postfächern von einer Organisation in eine Andere weil da der Outlook Cache durcheinander gekommen ist weil bei der Migration der LegacyExchangeDN geändert wurde. Das ist aber nie bei Kommunikation mit externen aufgetreten. Außerdem finde ich das seltsam das Exchange den LegacyExchangeDN von Unternehmen B mit der Maildomain von unternehmen A verknüpft (und da nichtmal die nach Adressrichtlinie richtige) und dann auch noch für externe Kommunikation. Gruß Tobias

Moin, wir migrieren von Exchange 2010 auf Exchange 2016 nun ist es ja so das CDO nicht mehr unterstützt wird, eine Abteilung verwendet diese Schnittstelle jedoch exzessiv in ihren VBS Scripten um automatisiert Mails zu versenden..... Funktionieren diese eigentlich simplen SMTP Funktionen über VBS/CDO mit Exchange 2016 auch nicht mehr? Oder macht die CDO Schnittelle da wirklich nur SMTP und es wird weiter funktionieren? Dazu konnte ich leider nicht wirklich viel finden :/ Gruß Tobias

Moin, naja das der WSUS nicht verteilt ist mir klar, wir setzen WSUS schon ein paar Jahre ein, bei Windows 7 haben wir jedoch keine große Differenzierung der Updates gemacht. Sie wurden einfach freigegeben und gut. Bei Windows 10 wollen wir das halt anders machen und ein verzögertes Deployment implementieren - eben wegen den Funktionsupdates die es mittlerweile gibt :) Verstehe ich es richtig, das es über die GUI nicht möglich ist anzuzeigen welche Updates für eine Gruppe noch nicht genehmigt wurden, wenn die Updates bereits für eine andere Gruppe freigegeben wurden? Ich gebe keine Updates für die Übergeordnete Gruppe "Alle Computer" frei sondern nur für die Untergruppen. Das Problem ist dann halt das ich zwar sehe was ich in RING-1 genehmigt habe, aber ich sehe nicht was ich in einer anderen Gruppe nicht genehmigt habe, aber eigentlich erforderlich wäre. Die Gefahr dabei ist dann, das wichtige Updates nach den Tests nicht installiert werden, weil man eben nicht sieht welche Updates eigentlich für die Gruppe nötig wären. Aber naja Microsoft will wahrscheinlich den SCCM verkaufen :)