Friesenjunge

An sich eine gute Idee, dachten wir zuerst ja auch. Aber wie mich Norbert eines besseren belehrt hat (im positiven Sinne ;)), ist gerade das Deaktivieren des Stores per GPO ein Enterprise-Feature, was ich per Design für einen Fehler halte. In meinen Augen ein Killer-argument... Sinnvoll wäre hier der Ansatz, den Store und zumindest die von MS mitgelieferten Bord-Apps einzeln per GPO sperren oder freigeben zu können. Und das ab den Pro-Editionen. Ich hoffe, MS besinnt sich noch, das zu ändern.

Also, Norbert, jetzt verstehe ich Deinen Ansatz ;-). Und dass die von MS derzeit gebotenen Eingriffsmöglichkeiten nicht optimal/praxisgerecht sind, da sind wir uns ja auch einig. Dass ich mein Deployment nicht von einer App abhängig mache, war meine Intention. Ich werde aber auf Deinen Hinweis hin für zukünftige Upgrades den Weg überdenken und optimieren, danke dafür. Bis zum nächsten Mal, Friesenjunge

Ich habe die Administrativen Vorlagen so installiert, wie es bei Microsoft beschrieben ist. Dann habe ich die Gruppenrichtlinie erstellt, die Einstellungen gesetzt und zunächst auf eine GPO verknüpft, in der nur ein paar Referenzmaschinen zum Test drin waren. Dann haben wir getestet, ob alles so weit OK ist und nach Freigabe die GPO auf die OU mit unseren Computerkonten verknüpft. Ich kann hier keinen Fehler im Deployment erkennen, zumal es ja (eigentlich) so funktioniert, wie es sollte. OK, bis auf die Ausnahme, dass die zwei Einschränkungen eigentlich unter Pro nicht ziehen sollten. Interessanterweise kann ich die zwei Punkte auch im Gruppenrichtlinieneditor nach Belieben an- und abschalten, am Client ein gpupdate und die Änderung greift. Und ich kann mir auch nicht vorstellen, dass das Upgrade, was ausschließlich über offizielle Werkzeuge von MS durchgeführt wurde, uns plötzlich einen Designfehler unterschiebt. Und nein, davon mache ich mein Deployment nicht abhängig, definitiv nicht. Ich wundere mich halt darüber, dass man sich bei MS in der Hinsicht scheinbar weniger Gedanken gemacht hat, als über andere Dinge. Klar gibt es kostenlose und gute Fremdanbieterprogramme als Taschenrechner, meine persönliche Meinung ist aber, so gut es geht Bordmittel zu nutzen. Der Taschenrechner ist hier sicher nur ein Beispiel, wenn auch eines, wo unsere User zuerst drüber gestolpert sind ;).​

Das Problem hatte ich weiter oben bereits beschrieben: Die mir zumindest bekannten GPO-Einstellungen bieten lediglich die Möglichkeit, den Store selbst sowie die Store-Apps in Gänze zu verbieten. Das ist recht unflexibel, da es im Gegensatz zur Foto-App kein im Installationsumfang enthaltenes Desktop-Pendant für den Taschenrechner gibt, auf den man ausweichen kann. Die GPOs wirken entgegen der Aussage in dem von Dir verlinkten Artikel auch bei uns in der Windows 10 Pro (Version1511). Warum? Egal, sie wirkt. Ich halte die Variante "Deinstalliere alles, was Du nicht haben willst" im Unternehmensumfeld für ziemlich daneben. Es gibt nicht umsonst die Möglichkeiten einer GPO, die Turnschuhadministration ja vermeiden soll, oder ;)? Wenn es, wie Du schreibst, (momentan) hier keine sinnvolle Möglichkeit seitens MS über GPO gibt, zumindest mal die MS-Board-Apps einzeln zu steuern (Bis auf Kalender, Skype und Mail, so steht's in der XLSX mit den einzelnen Einstellungsmöglichkeiten von MS), so ist das schade, aber auch nicht zu ändern​. Dann finden sich andere Lösungen. Viele Grüße aus Nordfriesland Friesenjunge

Nun ja, der Taschenrechner ist schon nützlich und warum, wenn Windows den mitbringt, ein zusätzliches (Fremd-)Programm installieren...

Moin Norbert, erstmal danke für Deine schnelle Antwort. Interessanterweise greift die in dem verlinkten Artikel beschriebene GPO, obwohl wir keine Enterprise-Versionen verwenden. Es geht mir darum, einzelne Apps zuzulassen und nicht per Gießkannenprinzip alles generell zu verbieten. Nicht alle vorinstallierten Apps sind kritisch oder gesprächig ;-) Viele Grüße Friesenjunge

​Moin zusammen, nachdem unsere Geschäftsleitung entschieden hat, das Angebot von Microsoft zum kostenlosen Upgrade anzunehmen, haben wir nun etliche Rechner auf Windows 10 aktualisiert. Natürlich haben wir nun zunächst über eine GPO namens "W10_Restrictions" die Nutzung der Store Apps (auch der Vorinstallierten) sowie des Stores selbst verboten. Davon sind ja leider auch ein paar sinnvolle Apps betroffen: Foto-App Taschenrechner Kennt jemand von Euch einen praktikablen Weg - möglichst per GPO - , einzelne Apps zuzulassen, quasi auf Basis einer Whitelist? Wie immer bin ich für jeden konstruktiven Tipp dankbar! Viele Grüße Euer Friesenjunge

Ja, Sunny, richtig. Ich stimme Dir auch voll zu. Manchmal ist es aber leider so, dass Prioritäten von anderen gesetzt/umpriorisiert werden. Ich sehe zu, es den Entscheidungsträgern "schmackhaft zu machen" WSUS asap neu zu implementieren. Nur möchte ich so etwas ungern einen Azubi machen lassen. ;) Auf jeden Fall vielen Dank, ich habe zumindest den Reg-Hack schon getestet und es hat nach Logoff/Login funktioniert. Wenn ich es jetzt noch schaffe, den WSUS fertigzubekommen, bevor sich Microsoft etwas neues dazu einfallen lässt, dann habe ich die ganze Miete...

Danke für die Tipps, ich werd's mir anschauen. Hatte ich ja schon geschrieben:

Moin zusammen, wir haben hier auf den Windows 7 Clients nun die Upgradebenachrichtigunge bekommen. Die PCs sind in einer AD, ein WSUS existiert (noch) nicht. Wir hatten hier eine große Migration in eine neue AD, daher ist bislang noch kein neuer WSUS aktiv. Das wollen wir nun nachholen. Nun meine Frage(n): würden wir mit einem neuen WSUS, auf dem das Upgrade gesperrt wird, dann die Meldung von den Clients wieder entfernt bekommen? Falls nicht, wie sollten wir am sinnvollsten vorgehen. Bitte keine Diskussion, warum wir das Upgrade nicht machen wollen, es ist nicht meine Entscheidung und ich habe mir bereits den Mund fusselig geredet. Bin für jeden konstruktiven Tipp dankbar. Viele Grüße Euer Friesenjunge

Alles klar, danke. Somit ist das Thema für mich gelöst und ebenso markiert ;)

So, als erstes: Herzlichen Dank an Norbert (aus HB) und Jan für die entscheidenden Tipps! Ich habe nun auf den beiden betroffenen Exchange die neu erstellten Zertifikate an die Dienste gebunden. Erste Tests ergaben, dass über OWA unmittelbar nach der Aktion schon die neuen Zertifikate verwendet wurden, bei der Verbindung mit Outlook dauerte es ein paar Minuten. @Sunny: Alte Zertifikate sind nach erfolgreicher Bindung in der EMS von mir gelöscht worden. Gestattet mir bitte eine letzte Frage: Muss ich auch über die EMS aktiv werden, wenn ich die Zertifikate rechtzeitig vor Ablauf verlängere? Oder bekommt der Exchange das mit, da das Zertifikat sich (vom Fingerprint her) nicht ändert? Viele Grüße von der Nordseeküste/dänische Grenze Friesenjunge

OK, Exchange scheint hier wohl etwas faul zu sein... Danke! Ich teste das und melde mich wieder.

Danke Jan! Das ist interessant: In der EMS werden mir bei dem alten Zertifikat die Dienste "IP.WS." angezeigt, welche ich im TechNet nicht finden kann...

Moin und herzlichen Dank für die schnellen Antworten! Wir setzen eine Exchange 2010 Standard ein: 14.030181.006 Der Befehl "Get-ExchangeCertificate" zeigt mir das von mir neu im IIS erstellte Zertifikat an. Wir wollen das Zertifikat für OWA und Outlook-Verbindungen einsetzen. Welche Dienstbezeichnung muss ich denn dann verwenden, um das Zert mit "Enable-ExchangeCert..." zu binden? Ich habe mir die Hilfe des cmdlets aufgerufen. Hier werden mehrere Dienste aufgelistet: IMAP (klar) POP (klar) UM (Unified Messaging?) IIS (wohl OWA) SMTP (klar) Federation (Was ist das?) Ich würde nun in der EMS folgenden Befehl eingeben und abschicken: Enable-ExchangeCertificate -Thumbprint <Fingerprint des Zertifikats> -Services POP,IMAP,SMTP,IIS Korrekt? Danke, bis hierhin habt Ihr mir schon einen entscheidenden Schritt weitergeholfen! [Nachtrag] Ich liebe dieses Forum! [/Nachtrag]

Moin zusammen, folgendes Problem: Wir betreiben eine PKI über mehrere Standorte hinweg. In dieser PKI wurden durch einen externen Dienstleister bei der Implementierung Zertifikate für unsere Mailserver erstellt. Leider sind diese abgelaufen, da wir es versäumt haben, diese rechtzeitig zu verlängern. Nun habe ich von dem Mailserver aus ein neues Zertifikat erstellt, dieses wurde vom PKI-Server auch ausgestellt. Der Mailserver identifiziert sich gegenüber den Clients aber nach wie vor mit dem abgelaufenen Zertifikat. Folgendermaßen bin ich vorgegangen: Beantragung eines neuen Zertifikats aus dem IIS [serverzertifikate] des Exchange heraus. Nach Ausstellung des neuen Zertifikats habe ich aus der IIS-Konsole "Zertifikate" dieses exportiert, und im Zertifikatsmanager des Exchangeservers (Computerzertifikate) in "Eigene Zertifikate" importiert. Das neue Zertifikat wird im PKI-Server als ausgestellt, signiert und gültig angezeigt, aber beim Verbindungsaufbau der Outlook-Clients mit dem Exchange wird nach wie vor das alte, abgelaufene Zertifikat angezeigt/verwendet, mit OWA verhält es sich genauso. Ich habe jedoch das alte Zertifikat auf dem PKI-Server noch nicht gesperrt oder gelöscht. Wie muss ich nun vorgehen, damit die Clients wieder ein gültiges Zertifikat zu sehen bekommen. Vielen Dank für Eure konstruktiven Vorschläge. Euer Friesenjunge

Technisch gesehen ist das ja kein Thema, dank "Media Creation Tool" von Microsoft. Es ging mir nur um die Lizenzrechtliche Einordnung, und da entspricht meine Meinung der von Norbert. Aber man will sich ja absichern, um auch dieses Jahr eine saubere Lizenzbilanz aufweisen zu können. Schon mal herzlichen Dank an Euch :)

Moin zusammen, derzeit wird ja Windows 10 als Upgrade fleißig von Privatanwendern in Anspruch genommen. Wie schaut es in folgender Konstellation aus: Ein Unternehmen kauft neue PCs, auf denen Windows 8.1 Pro (oder als Downgrade Windows 7 Pro) vorinstalliert ist. Die Rechner sind zu dem Zeitpunkt nicht Mitglied einer AD (Domäne), da fabrikneu. Somit ist technisch das Upgrade ja möglich, auch ohne die "Get Windows 10 App", die entsprechende Upgradesoftware wird ja von Microsoft selbst zum Download bereit gestellt. Würde man einen Lizenzverstoß begehen, diese neuen Rechner auf 10 Upzugraden, bevor man sie zu AD-Mitgliedern macht? Vielen Dank für jeden konstruktiven Beitrag! Wichtig: Es geht mir nicht darum, einen Lizenzverstoß zu begehen, sondern darum, mich rechtzeitig schlau zu machen, um einen Lizenzverstoß zu vermeiden ;) Viele Grüße Euer Friesenjunge

Erstmal Danke für Eure Antworten! Kurz an Norbert: Das ist wohl historisch bedingt, auf jeden Fall ist es eine Anforderung, die umzusetzen ist und von mir auch nicht wegar´gumentiert werden kann (Obst halt)... Nun zu Deinen Punkten, Robert: Das Einzige, was hier anscheinend greift, ist die DefaultThrottelingPolicy. Deren Wert habe ich nun auf "10" gesetzt und den IMAP-Dienst neu gestartet. Im Eventlog kann ich keine Einträge finden, die auf eine Ablehnung einer Anmeldung hindeuten. Leider funktioniert es aber immer noch nicht. Muss ich über die Exchange-Console die Richtlinie evtl. neu laden? Vielen Dank und viele Grüße Markus

Moin zusammen, haben hier ein Phänomen, bei welchem Ihr bestimmt weiterhelfen könnt. Wir betreiben seit kurzem einen Exchange 2010. Die meisten User sind über Outlook angebunden. In der Grafikabteilung gibt es etliche Macs, deren Postfächer über IMAP angebunden sind. Manche Postfächer werden von mehreren Plätzen gleichzeitig verwendet. Nun haben wir gerade auf diesen Postfächern das Problem, dass sich je Postfach max. 5 Clients gleichzeitig verbinden können. Gibt es einen einfachen, lizenzkonformen Weg, diese Zahl zu erhöhen, sagen wir auf 10? Bin für jeden Tipp dankbar. P.S.: Habe im Technet eine Variante gesehen, die mir zwar plausibel aber recht kompliziert zu sein scheint: http://technet.microsoft.com/de-de/library/dd297964%28v=exchg.141%29.aspx Ich suche nach einer Lösung, die einfacher zu bewerkstelligen ist. Vielen Dank und herzliche Grüße Friesenjunge [edit by Friesenjunge]Rechtschreibung korrigiert[/edit]

Moin zusammen, habe hier ein extrem seltsames Phänomen: Ein User beklagte sich, dass sein Outlook 2010 sich nicht mit dem Exchange (2003) verbinden kann. OK, das hatten wir schon einmal, der User war mehrere Wochen außer Haus. Lokale Mailkonfiguration aufgerufen, die Postfachanbindung gelöscht und Outlook gestartet. Es fragte auch brav, ob ein Konto eingerichtet werden soll. Alles soweit OK. Sein Exchange-Postfach angebunden und es verband sich auch sofort. Nur: Es sind nur noch Mails enthalten, die nach dem 31.07.2014 versandt oder eingetroffen sind. Sein Kalender ist komplett leer. Ich dachte: Kein Problem, wir haben ja ein Backup. Hier stellte sich heraus, das selbst das älteste verfügbare Backup den selben Stand erzeugt. Also Stichtag 31.07.2014. Was kann ich tun, um Herauszufinden, was schief ging Das evtl. noch zu beheben Bin wie immer für jeden Tipp dankbar! Viele Grüße Euer Friesenjunge

Moin zusammen, wieder einmal schlage ich mich in unserer Testumgebung rum. Folgendes soll erfolgen: Ein Benutzer (inkl. Postfach auf "altem" Exchange in "alter" AD) soll in seinem bestehenden Postfach eine Weiterleitung zu seinem Pendant in der "neuen" AD auf dem "neuen" Exchange erhalten. Richte ich auf dem Alt-Exchange eine Weiterleitung auf den Useraccount in der neuen, vertrauten AD ein, erhalte ich folgende Fehlermeldung: Es besteht zweischen den Umgebungen eine explizite, gegeseitige Vertrauensstellung. Wenn ich im Alt-System einen Kontakt anlege, der die Mailadresse des Users in der neuen AD hat, funktioniert es ohne Fehler. Wir möchten aber in der Übergangs- und Migrationsphase möglichst wenig zusätzliche Handarbeit haben. Wer kann mir einen Tipp geben, wo ich das abstellen kann. Ich tippe auf ein Rechteproblem... Besten Dank und bis dann Euer Friesenjunge

Moin zusammen, folgende Frage: An welcher Stelle unter Exchange 2010 Standard kann ich die Beschränkung der maximalen Dateigröße für Attachments festlegen bzw. abschalten? In unserer (noch Test-)Umgebung ist derzeit der Versand von Nachrichten mit Attachments größer 10 MB nicht möglich. Vielen Dank und kollegiale Grüße Friesenjunge

Ja, Daniel, die Tools von Microsoft waren früher eher bescheiden. Inzwischen hat sich da glücklicherweise einiges getan! Auf jeden Fall klappt es jetzt, wenn auch nicht 100% so, wie geplant, aber das stört nicht wirklich. Manchmal muss man andere Wege gehen. Auf jeden Fall vielen Dank an alle für Eure Tipps und Lösungsansätze!

Auch ohne den CN wurde der Fehler ausgegeben. Daher hatte ich ihn ja mit reingenommen. Aber es ist im Moment auch nicht so dramatisch, da wir sehr gut im Zeitplan der Migration sind. Ob ich die User aus "Users" oder aus der eigentlichen Ziel-OU verschiebe, ist nicht wirklich entscheidend. Da wir das Feld "Description" im Unternehmen im Userobjekt nicht verwenden, habe ich hier fest den Wert "Scriptgenerierter, deaktivierter Account" hinterlegt. Dann muss ich nur noch die User sortieren und dann verschieben. Wenn die User dann nach und nach (geplanter Parallelbetrieb) aktiv gehen, wird der Hinweis entfernt. Ursprünglich war geplant, das mit CSVDE umzusetzen, das scheitert aber an der maximalen Spaltenanzahl beim Import. Das hatten Nils und Norbert auch in Ihrem Buch "Windows Server 2003 - Die Expertentipps" (MS Press 5604, ISBN 9783866456044) geschrieben. Dann stieß ich auf die Powershell (war über den Scripting Guy) und war sofort "angefixt"... ;)