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. 

 

vor 4 Minuten schrieb Squire:

Läuft eigentlich ganz gut über WSUS - was bei uns aufgefallen ist ... die Treiber der Desktops/Notebooks sollten nicht steinalt sein - sprich man sollte die auch regelmäßig aktualisieren. Dann klappt das Feature Upgrade auch via WSUS (machen wir seit 1511 so ... ). Das 1903er braucht relativ wenig Zeit bei Reboot ... und das Upgrade auf 1909 läuft prinzipiell wie ein normales kummulatives Update (da gibt es per WSUS ein sog. Enabler Paket)

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

vor 5 Stunden schrieb NorbertFe:

Nee, aber Microsoft. ;)

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  :)

Moin,

 

wir betreiben einen WSUS auf Windows Server 2012 R2, der läuft mittlerweile auch ganz gut und verteilt fleißig Updates.

Updates will ich folgendermaßen Verteilen:

 

Ring-1

Alle Rechner die der AD Gruppe "Ring-1" zugeordnet sind bekommen per GPO die WSUS Gruppe Ring-1 zugewiesen.

Die Rechner in dieser Gruppe erhalten kurz nach Release alle Updates / Funktionsupdates. Sind also die Testrechner..

 

Ring-2

Sicherheitsupdates werden hier sofort freigegeben. Nach ersten erfolgreichen Tests in Ring-1 werden hier auch die Funktionsupdates freigegeben.

Es handelt sich um produktive Clients von Benutzern die freiwillig bereits früh auf neue Windows 10 Builds wechseln wollen.

 

Alle anderen 

Alle nicht einem Ring zugeordneten Clients werden nach Geräte Typ (Labor, Notebook, PC, Server...) per GPO der entsprechenden WSUS Gruppe zugeordnet. 

Wenn in Ring-1 und 2 Funktionsupdates getestet wurden, werden diese auch hier freigegeben.

 

 

Das klingt ja eigentlich ganz simpel und die Zuordnung der Clients funktioniert auch problemlos. Allerdings ist es für mich nahezu unmöglich für eine Computergruppe die Updates aufzulisten die Erforderlich aber nicht freigegeben sind...

Wenn man eine Updateansicht erstellt, hat man nur die Möglichkeit Updates einzublenden die für eine Gruppe genehmigt wurden... das interessiert mich aber nicht :D 

Gibt es da Tricks? Oder bin ich einfach blind?

 

Mich würde interessieren wie ihr das macht? 

 

 

Gruß

Tobias

So, hab jez einfach mal das CU7 für Exchange 2016 installiert, nach dem die Installation auf dem ersten Server etwas rumzickte (Wollte die Dienste nicht mehr starten und brach das update immer ab) laufen nun auch die Kalenderfreigaben wieder wie sie sollen. 

Moin,

 

Natürlich nicht zu ende gelesen ;) war schon zu spät hab wohl schon halb geschlafen. 

Hier die kompletten Infos:

 

Exchange-01
[PS] C:\Users\administrator.BS\Desktop>Get-ExchangeServer|ft Name,Edition,AdminDisplayVersion -Auto
Name           Edition AdminDisplayVersion
----           ------- -------------------
EXCHANGE-01 Enterprise Version 14.3 (Build 123.4)
EXCHANGE-02   Standard Version 14.3 (Build 123.4)
EXCHANGE-03   Standard Version 14.3 (Build 123.4)

[PS] C:\Users\administrator.BS\Desktop>(Get-ExchangeServer exchange-01).AdminDisplayVersion

Major                     : 14
Minor                     : 3
Build                     : 123
Revision                  : 4
FilePatchLevelDescription :
[PS] C:\Users\administrator.BS\Desktop>GCM exsetup |%{$_.Fileversioninfo}
ProductVersion   FileVersion      FileName
--------------   -----------      --------
14.03.0361.001   14.03.0361.001   C:\Program Files\Microsoft\Exchange Server\V14\bin\ExSetup.exe

 

Exchange-02

[PS] C:\Windows\system32>(Get-ExchangeServer exchange-02).AdminDisplayVersion

Major                     : 14
Minor                     : 3
Build                     : 123
Revision                  : 4
FilePatchLevelDescription :

[PS] C:\Windows\system32>GCM exsetup |%{$_.Fileversioninfo}

ProductVersion   FileVersion      FileName
--------------   -----------      --------
14.03.0361.001   14.03.0361.001   C:\Program Files\Microsoft\Exchange Server\V14\bin\ExSetup.exe

 

exchange-03

[PS] C:\Windows\system32>(Get-ExchangeServer exchange-03).AdminDisplayVersion

Major                     : 14
Minor                     : 3
Build                     : 123
Revision                  : 4
FilePatchLevelDescription :

[PS] C:\Windows\system32>GCM exsetup |%{$_.Fileversioninfo}

ProductVersion   FileVersion      FileName
--------------   -----------      --------
14.03.0351.000   14.03.0351.000   C:\Program Files\Microsoft\Exchange Server\V14\bin\ExSetup.exe

Exchange
[PS] C:\Users\exchange\Desktop>(Get-ExchangeServer exchange).AdminDisplayVersion

Major                     : 15
Minor                     : 1
Build                     : 1034
Revision                  : 26
FilePatchLevelDescription :

 

[PS] C:\Users\exchange\Desktop>GCM exsetup |%{$_.Fileversioninfo}

ProductVersion   FileVersion      FileName
--------------   -----------      --------
15.01.1034.032   15.01.1034.032   C:\Program Files\Microsoft\Exchange Server\V15\bin\ExSetup.exe

 

DAG-01
[PS] C:\Windows\system32>(Get-ExchangeServer dag-01).AdminDisplayVersion

Major                     : 15
Minor                     : 1
Build                     : 1034
Revision                  : 26
FilePatchLevelDescription :

[PS] C:\Windows\system32>GCM exsetup |%{$_.Fileversioninfo}

ProductVersion   FileVersion      FileName
--------------   -----------      --------
15.01.1034.032   15.01.1034.032   C:\Program Files\Microsoft\Exchange Server\V15\bin\ExSetup.exe

 

DAG-02
[PS] C:\Windows\system32>(Get-ExchangeServer dag-02).AdminDisplayVersion

Major                     : 15
Minor                     : 1
Build                     : 1034
Revision                  : 26
FilePatchLevelDescription :

 

[PS] C:\Windows\system32>GCM exsetup |%{$_.Fileversioninfo}

ProductVersion   FileVersion      FileName
--------------   -----------      --------
15.01.1034.032   15.01.1034.032   C:\Program Files\Microsoft\Exchange Server\V15\bin\ExSetup.exe

Moin,

 

die Server stehen im selben Netz, daher kein Gerät dazwischen.

 

EXCHANGE-01 Enterprise Version 14.3 (Build 123.4)
EXCHANGE-02   Standard Version 14.3 (Build 123.4)
EXCHANGE-03   Standard Version 14.3 (Build 123.4)

EXCHANGE    Enterprise Version 15.1 (Build 1034.26)
DAG-01      Enterprise Version 15.1 (Build 1034.26)
DAG-02      Enterprise Version 15.1 (Build 1034.26)

 

Was mich da jez etwas irritiert ist die Buildnummer von den Exchange 2010ern, wenn ich mich recht erinnere ist 123.4 eine sehr alte version. Ich habe die Rollups aber alle installiert und ein _

[PS] C:\Users\administrator.BS\Desktop>Get-Command ExSetup | ForEach {$_.FileVersionInfo}

ProductVersion   FileVersion      FileName
--------------   -----------      --------
14.03.0361.001   14.03.0361.001   C:\Program Files\Microsoft\Exchange Server\V14\bin\ExSetup.exe

 

wirft auch die richtige Version raus. Auch Windows Update zeigt mir an das RU18 erfolgreich installiert wurde. 

Hi,

 

ich habe aktuell eine Koexistenz von Exchange 2010 und Exchange 2016 da wir eine Migration durchführen. 

Das meiste Funktioniert auch tadellos, nun habe ich noch ein Problem mit Kalenderfreigaben.

 

Mein Konto und das meines Kollegens ist bereits auf den neuen Exchange 2016 umgezogen, wir setzen beide Outlook 2016 ein und die Migration war erfolgreich.

Auch der Zugriff auf Öffentliche Ordner (auf dem alten Exchange) laufen über das Proxy Postfach absolut problemlos. 

 

Nun habe ich das Problem, das ich auf seinen Kalender nicht mehr zugreifen kann, Outlook meldet "keine Verbindung." auch das entfernen und das neu hinzufügen in mein Outlook hat nichts gebracht.

Öffne ich seinen Kalender in OWA, kann ich wie gewohnt die frei/gebucht Zeiten sehen. 

 

Öffne ich ein Freigegebenen Kalender auf dem alten Exchange habe ich das Problem nicht, jedoch berichten andere Testuser das sie das Problem auch mit Benutzern auf dem alten Exchange haben. 

Ich habe aktuell keine Idee wo ich da suchen soll, weil Outlook natürlich auch nicht die kommunikativste Software bei Fehlern ist....

 

 

Kennt jemand das Symptom oder kann mir einen Tip geben wo ich nachschauen kann?

 

 

Gruß

Tobias

 

Ergänzung:

- Das Problem tritt unabhängig von Outlook Profil / Rechner auf

- Im Outlook Verbindungsstatus sehe ich, das Outlook eine HTTPS Verbindung zu dem entsprechenden Postfach aufbaut

Moin,

 

also Exchange ist aktuell, habe ich neulich erst wegen der bevorstehenden Migration auf 2016 gepatcht.

Outlook ist ebenfalls aktuell, und ob irgendwelche Regeln aktiv sind habe ich natürlich selber geprüft ;)

 

Nun habe ich die Option /cleanviews getestet und Tadaa, die Mail ist  zu sehen.... sehr seltsam ;)

 

 

Danke & Gruß

Tobias

Moin,

 

ich habe jez schon ein Paar mal das Phänomen gehabt, das E-Mail in Outlook nicht sichtbar waren aber in Outlook Web Access schon. 

Die E-Mail fehlt einfach in der Ansicht als wenn sie nicht da wäre.

 

Das ist natürlich sehr unglücklich weil so schnell Mails übersehen werden. 

Im Synchronisationsprotokoll im Outlook tauchen diesbezüglich auch keine Fehler auf... Auch Filterregeln sind nicht eingerichtet.

 

hat da jemand eine Idee woran das liegen kann?

 

 

Gruß

Mr.Schrotti

Das viel Ärgerlichere daran ist eigentlich, dass die Probleme bekannt sind, aber keine Lösungen angeboten werden. es kann eigentlich nicht so schwer sein, ein Update anzubieten, welches zumindest zukünftig diese Probleme behebt. Das löst dann zwar nicht das konkrete Problem wenn ein altes Update vorliegt, aber verhindert, dass mir das bei jedem Client passiert. ist aber offenbar bei MS nicht vorgesehen. Sieht für mich nach "Aussitzen" bis neue Build kommt aus.

IMHO kann man MS da schon Vorsatz vorwerfen, da die Probleme bekannt sind, das defekte Upgrade aber trotz dem verteilt wird.

 

Naja... andererseits hab ich im WSUS nur Preview Qualitätsrollups für 7, 8.1 und die dazugehörigen Serverversionen gefunden habe und nicht für Windows 10.

Für alle Systeme außer W10 sind diese Updates da.... Schlimm genug, denn die Systeme sind bei uns Produktiv im Einsatz und ich will keine Preview Updates in einer Produktiv Umgebung, wenn ich weis das MS sogar Finale Updates gerne verbockt :D

 

Das für den WSUS ist wahrscheinlich einfach nur ein Abfallprodukt vom SCCM der das im WSUS benötigt. Abgesehen davon gehe ich stark davon aus, dass es einfach darum ging, möglichst schnell für eine Verbreitung von Windows 10 zu sorgen.

Mag sein, hat aber die Windows Update Funktion auf allen Rechnern gestört die versucht haben das "upgrade" zu installieren. Musste nen Registry Key löschen um wuauserv davon zu überzeugen das gar kein neustart notwendig ist ... Seit dem lass ich keine Updates mehr automatisch zu, einfach viel zu riskant.

Wenn Microsoft eine schnelle Verbreitung im Firmenumfeld will, sollen sie ihren Job ordentlich machen und das ganze System uns Admin schmackhaft machen und nicht versuchen aufzuzwingen. Ich meine das was uns hindert Windows 10 einzuführen sollte für Microsoft eine Leichtigkeit sein zu ändern.

Aber man legt mehr heutzutage bei einer Software mehr wert auf den Coolness Faktor als auf die Software Qualität... Sieht man an dem "Creators Update"

Microsoft hat schon viele solche 'Kleinigkeiten' bei Windows 10 bei Funktionen für Unternehmen verbockt.

Ich finde, die Updatefunktionalität zu zerstören ist schon etwas mehr als eine Kleinigkeit ;) sowas DARF eigentlich nicht passieren und zeugt nur davon das Microsoft immer noch kein ordentliches Qualitätsmanagement besitzt.

 

Dieses ganze Insider Build Gedöns hat scheinbar auch nix gebracht ;) und die Tatsache das der WSUS mir "Vorschaupdates" als "Update" klassifiziert versucht zu verkaufen macht mir ehrlich gesagt ziemlich angst ...

Allgemein wird die Art der verfügbares "Updates" immer unübersichtlicher und Microsoft schafft es nicht eine Brauchbare Klassifizierung im WSUS zu implementieren.

 

- Sprachpakete sind KEIN Update (im WSUS schon)

- Vorschau (BETA) Updates sind kein UPDATE sondern eine BETA und sollten auch so bezeichnet zu werden

- Windows 7 => 10 Upgrades haben auf einem WSUS gar nix zu suchen

 

Man muss sowieso schon irre aufpassen beim freigeben von Updates auf dem WSUS und jez muss man auch noch aufpassen das man sich durch ein Update/Upgrade nicht die ganzen Clients vom WSUS abhängt...

 

Langsam kotzt dieses Geschludere von MS einfach nur noch an.

Moin,

 

ja nach dem Update scheint es zu funktionieren - wo er jedoch die Updates herbekommt habe ich jez nicht überprüft...

Dafür das er den WSUS Ignoriert spricht dass der WSUS noch keinen neuen Status vom Client bekommen hat...

 

Da hat Microsoft aber echtn Bock geschossen mit diesem Upgrade... ich hoffe das so etwas zukünftig nicht mehr auftreten wird.

Denn prinzipiell gefällt mir Windows 10 ziemlich gut.

 

Produktiv ist W10 bei uns zum glück noch nicht, wir testen es nur auf Testsystemen von daher unkritisch aber trotz dem Ärgerlich, zumal 1511 mit WSUS auch schon nicht so einfach war.