Userle

Das funktioniert tatsächlich. Auch wenn es am Ende des Tages dann wohl ohne Automapping gehen muss. Berechtigung wird nur via Gruppe erteilt.

Das ist das was letztlich daraus folgt. Das es unsupportet ist weiß ich nicht. Der Exchange 2016 ist nur der Zwischenschritt vom Exchange 2010 zu 2019. Wäre längst durch, wenn der ehemals zuständige MA das Unternehmen nicht vorzeitig verlassen hätte. Das mit dem Vollzugriff Benutzerbezogen werde ich mal testen. Danke für den Tip.

Ich verstehe Deine Frage nicht. Die berechtigten Benutzer sind alle Mitglied der Gruppe. Das Automapping habe ich jedoch Benutzerbezogen versucht mit geschildertem Ergebnis.

Hallo Gemeinde, ich schlage mich gerade mit einem Problem rum und hoffe von Euch ein paar gute Denkanstöße zu bekommen. Umgebung: Windows Server 2019 Exchange 2016 Office bzw. Outlook 2021 LTSC auf den Clients Windows 10/Windows 11/Windows 2019 (Terminal) Alles auf dem aktuellen Patchstand. Problem Beschreibung: Ich habe eine Shared Mailbox angelegt. Für die Berechtigung der User (Vollzugriff) habe ich eine E-Mail aktivierte universelle Sicherheitsgruppe angelegt. Wenn ich nun das Attribut "mxExchDelegateListLink" bearbeite und die Benutzer hinzufüge, hat das zur Folge, dass Outlook nicht mehr startet. Es kommt eine Meldung, dass die Kommunikation mit dem Exchange nicht möglich ist. Lasse ich das Attribut leer, startet Outlook wieder ganz normal. Ich kann das Postfach auch manuell hinzufügen. Das klappt ohne Probleme. Habt Ihr eine Idee dazu? Am liebsten wäre mir sogar ein Automapping über die Sicherheitsgruppe wenn das irgendwie ginge. Greetings Ralf

Also Lizenz Beratung ist hier im Board wie immer schwierig und wegen der rechtlichen Komponente nicht erwünscht und erlaubt. Ich kann Dir jedoch trotzdem einen Tipp geben. Ich hatte kürzlich an einem MS Lizenz Training teilnehmen dürfen, durchgeführt durch einen sehr kompetenten Menschen, der wie ich es verstanden habe auch beratend tätig ist. In der Hoffnung gegen keine Regel zu verstoßen hier einmal ein Link: http://www.skilllocation.com Greetings Ralf

Das Problem hatten wir früher auch vereinzelt. Am Ende des Tages haben wir uns dazu entschlossen nur noch mit einer Freigabe pro Fileserver zu arbeiten. Soll heißen wir haben eine Art "root" erstellt und darunter die gesamte Filestruktur abgebildet. Der Rest wird via NTFS Berechtigungen gesteuert incl. Sichtbarkeit von Ordnern. Zu Deinem geschilderten Anwendungsfall: Liegen die Freigaben möglicherweise "ineinander"? Also so: \\Server\Freigabe1 - Ordner 1 - Ordner 2 --> \\Server\Freigabe2 Wäre eine mögliche Fehlerquelle. Greetings Ralf

Dann bliebe ja entweder nur ein möglicherweise eingeräumter "Vollzugriff" auf das Postfach übrig oder aber der Benutzer, der den Zugriff hat, hat den Kalender mit den Credentials des Kalender Besitzers geöffnet. Beides wäre natürlich ziemlich "bescheiden". Greetings Ralf

Am einfachsten sollte es doch mit Powershell über "Get-MailboxFolderPermission -Identity *Postfach*:\Kalender" gehen. Wenn der betreffende User dort aufgelistet wird ist es sowieso klar, sollten Gruppen aufgelistet werden müsste die Mitgliedschaft des Benutzers geprüft werden. Greetings Ralf

Jau Jan, das ist tatsächlich der nächste Schritt . Greetings Ralf

Hallo Gemeinde, ich könnte gerade einmal wieder in jede zur Verfügung stehende Tischplatte beißen. Wir haben einen Softphone Clienten (MiVoice 2380). Dieser bringt auch ein Add-In für Outlook mit. Leider sieht es so aus, dass dieses Add-In nur dann funktioniert, wenn der Benutzer Mitglied der lokalen Gruppe Administratoren ist. Es ist klar das dies ein absolutes NoGo ist. Habt Ihr Ideen dazu wie man das Add-In auch ohne Admin Rechte zur Arbeit bewegen kann? Greetings Ralf

Also grundsätzlich habe ich immer Interesse an Boardtreffen. Allerdings kann ich derzeit auf Grund einiger privater Umstände immer nur sehr kurzfristig und von heute auf Morgen planen. Daher kann ich jetzt noch keine feste Zusage geben. Was den Tag angeht, so würde ich einen Freitag präferieren. Ich werde mal TheSpawn pieksen, ob er ggfs. auch Lust hätte. Greetings Ralf

Hast Du da eine Quelle? Also meiner Erfahrung nach funktioniert das auch mit "aktualisieren".

Wenn die Drucker nicht über einen Druckserver gemappt werden wird das gehen. Aber auch nur für den Fall der netzwerkseitigen "Nicht Erreichbarkeit". Alle anderen möglichen Fehler ziehen da nicht. Mappst Du die Drucker direkt? Weil wenn Du die Drucker über einen Druckserver mappen würdest dürfte das IMHO eigentlich keine Auswirkung auf die Anmeldezeiten haben, da der Drucker dann verbunden wird und der Status des Druckers schlicht so gesetzt wird wie er auf dem Druckserver ist, also auf Offline. Greetings Ralf

Da gehe ich inzwischen auch von aus. Wie bereits geschrieben, werden die durchgereichten Drucker in der Druckerliste aufgeführt, sind auch ausführ- und nutzbar, aber das mit dem "Standard Drucker" bekommt die Software warum auch immer nicht hin. Es scheint so zu sein, dass die Anwendung den Standard Drucker aus der Registry nimmt und dort steht tatsächlich der MS-PDF als Standard bzw. default drin. Das ist auch tatsächlich etwas, was mich verwirrt. In der Registry unter HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows steht als Device der MS-PDF Drucker drin. In der Systemsteuerung wird jedoch der durchgereichte Drucker als Standard angezeigt (wenn man sich via mstsc am Server anmeldet). Ich hätte erwartet, dass der Registry Eintrag angepasst wird. Easy Print und die Drucker hatte ich bereits einmal gelöscht. Da wird es dann noch spannender. Die Software hat einen eigenen PDF Erzeuger integriert. Dieser wird dann als Drucker vorgeschlagen. Ich belasse es jetzt erst einmal dabei und werde mal mit meinen Kontakten beim Anbieter parlieren und die mal befragen und ggfs. anregen da nochmal dranzugehen. Auf jeden Fall danke an Alle die sich hierzu Gedanken gemacht haben. Greetings Ralf

Der Standard Drucker wird nicht von Windows verwaltet. Innerhalb der RemoteApp kann ich schwer feststellen was in der Systemsteuerung steht. Da die Software jedoch den MS-PDF als ersten Drucker vorschlägt muss davon ausgegangen werden, dass dieser als Standard in der Systemsteuerung hinterlegt ist. Ich schrieb ja bereits: Es ist macht mich einfach kirre, dass wir verschiedenste RemoteApp Server für verschiedene Anwendungen haben. Alle sind im Prinzip identisch konfiguriert. Der einzige Unterschied ist die jeweilige Anwendung die gepublished wird. Auf allen funktioniert die Drucker Zuordnung wie gewünscht incl. Standard Drucker. Nur bei der Zeiterfassung nicht. Dort sind zwar alle Drucker in der Sitzung durchgereicht, aber Standard ist und bleibt immer MS-PDF.

Erst einmal danke für die bisherigen Antworten. Leider geht das am eigentlichen Problem bzw. der Fragestellung vorbei. Ich versuche mich noch einmal klarer auszudrücken: Ein Benutzer arbeitet z.B. an einem Win10 PC. Er hat einen Netzwerkdrucker auf diesem Win10 Client als Standard Drucker eingerichtet. Wir nennen diesen Drucker der Einfachheit halber mal Drucker A. Er startet die RemoteApp, welche so eingestellt ist, dass Drucker in die Remote Sitzung übergeben werden und auch den Standard Drucker ersetzen. Wenn die App dann gestartet ist, zeigt das Programm zwar den Drucker A in der Druckerauswahlliste an, aber schlägt immer den MS-PDF Drucker als Standard vor. Prüfe ich auf dem Remote Server die Registry Einträge, so kann ich ersehen, dass der MS-PDF Drucker tatsächlich als Standard definiert ist. Melde ich den gleichen Benutzer nicht über die Remote App sondern als normale RDP Sitzung via mstsc an, so steht in der Registry immer noch der MS-PDF Drucker als Standard, jedoch in der Systemsteuerung Drucker wird der Drucker A als Standard angezeigt. Starte ich dann das Programm wird auch der richtige Drucker, also Drucker A vorgeschlagen. Mir will nicht in den Kopf warum das mit der RemoteApp nicht klappt. Wir haben noch diverse andere RemoteApps, deren Konfiguration 1:1 identisch sind, außer natürlich die Software die gestartet wird. Bei allen funktioniert die Drucker Zuordnung wie gewünscht nur bei der einen nicht.

Wahrscheinlich bin ich zu blond, aber unter dem Begriff Win32_Printer gibt es nur einen Eintrag in der Registry und dort existieren keine Einträge für Drucker. Wobei mich ganz kirre macht:

Hallo Boardies, in einer Windows Server 2019 Umgebung werden verschiedene Programme als RemoteApp bereitgestellt. Alle diese Apps sind so konfiguriert, dass die Drucker des Clients in die Sitzung übergeben werden und auch den Standard Drucker übernehmen. Bei Allen Anwendungen klappt dies ohne Probleme mit Ausnahme einer Software für Zeiterfassung. Hier sind zwar die durchgereichten Drucker auswählbar, jedoch ist immer der Microsoft PDF-Drucker als Standard hinterlegt. Ich hab das nun relativ ausgiebig analysiert und folgendes dabei festgestellt: im HKEY User der Benutzer ist der Microsoft PDF Drucker tatsächlich als Standard hinterlegt. Melde ich den Benutzer via MSTSC an dem Server an, ist das immer noch so, jedoch wird in der Systemsteuerung der durchgereichte Drucker als Standard Drucker angezeigt. Das Programm greift jedoch immer noch stumpf auf den Microsoft PDF Drucker als Standard zu. Der Support des Softwareanbieters sagt dazu, dass die Software auf die Windows Druckeinstellungen zurückgreift und es innerhalb der Software keinen Parameter gäbe, der am Standard Drucker dreht. Eine weitere Merkwürdigkeit: Im Default User ist gar kein Standard Drucker angegeben. Trotzdem erhält jeder neue User automatisch den Microsoft PDF Drucker als Standard in der Registry hinterlegt. Wo ist das Brett vor meinem Kopf? Greetings Ralf

Das liegt nur am Fachkräftemangel "Licht aus" ist eine verantwortungsvolle Aufgabe und kann als solche nur von Experten ausgeführt werden und dem nicht unerheblichem Krankenstand. Wir hätten längst dem Board Azubi eine Einweisung geben sollen....@PadawanDeluXe antreten!

Mal so ins Blaue gefragt: Die Zeiten auf Deinen Geräten sind aber schon synchron oder? Nicht das der betroffene Client zu sehr abweicht. Vielleicht hilft Dir ja auch dieser Link weiter: Computerkennwörter, der Secure Channel und die Fehlermeldung „Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden” - Weisheiten - der Netz-Weise Blog (netz-weise-it.training) Greetings Ralf

Damit kein falscher Eindruck entsteht: Das war nicht nur für den Eimer ;) sondern auch fürs leibliche Wohl:

Dann warten wir auf Dich

Ich werde dann auch so in ca. 20 Minuten die Socken scharf machen. Bis gleich also.

Der Userle glaubt immer an das Gute

Das verwirrt mich total. Bisher bin ich davon ausgegangen, dass an einer Uni das Netz professionell betreut und verwaltet wird. Der offensichtlich "sanktionierte" Benutzer muss sich ja trotzdem an dem PC authentifizieren (daher verwirrt mich der Teil mit "ohne Benutzerkennung"), somit können doch Regeln auf ihn wirken. Im einfachsten Fall eine GPO die ihn an einen Dummy Proxy schickt wenn er Internet verwenden will. Allerdings würde ich erwarten, dass der Zugang zum Internet in einer Uni sowieso durch einen Proxy läuft und dieser wiederrum mit Profilen läuft á la Black- oder Whitelist z.B. oder eben halt gar keinen I-Net Zugang. Das ganze Benutzerabhängig. Wenn Du hier konkrete Hilfe erwartest solltest Du das Szenario und den Prozess der dahintersteckt so genau wie möglich schildern, incl. der Infos wie das Netzwerk generell aufgebaut ist. Greetings Ralf