Beiträge von illumina7

    Also nur falls das Problem mal wieder jemand haben sollte, konnte es zumindest lösen, wenn auch nicht finden.
    Habe dem User, der trotz gesetzter Berechtigungen, keinen Zugriff auf die Kalender hatte, in der ecp Vollzugriff auf die entsprechenden Postfächer gegeben. Outlook bei dem User gestartet, gewartet bis fertig synchronisiert, dann die Berechtigungen "Vollzugriff" wieder entfernt.
    Anschließend durfte der User auf alle freigegebenen Kalender zugreifen (wie eigentlich auch eingestellt).


    Jemand eine Idee, was die Ursache sein könnte?


    Zumindest ist der Fehler erstmal beseitigt...

    CU3 erfolgreich eingespielt (vorher natürlich Schema und AD vorbereitet), keine Änderung bei dem betroffenen Benutzer. Im OWA habe ich es aber nochmal ausgiebig getestet, dort funktioniert der Zugriff des oben genannten User A auf die Kalender der User D-G. Bin echt etwas ratlos aktuell...
    Wäre für jeden Tipp dankbar.

    Hallo Ihr,
    habe einen interessanten Fehler, komme irgendwie nicht weiter und finde auch online nichts Hilfreiches.


    Kurz zur Umgebung, ESXi Host mit u.a. folgenden Gästen:
    - Winserver 2012R2 Std mit Exchange 2016 CU1
    - Winserver 2012(non-R2) Std als WTS mit Office 2016 Std (aktueller Patchlevel)


    Outlook ist über Autodiscover automatisch eingerichtet, läuft 1a. Jeder Benutzer hat einen eigenen Kalender, der für alle anderen User mit Vollzugriff "Besitzer"(OWNER) freigegeben ist.
    Alle anderen haben alle Kalender aller Kollegen mit verbunden und tauschen untereinander Termine aus. Probleme gibt es nur bei einem User A, dieser hat Zugriff auf die Kalender der User B-G.
    Die Kalender der User B,C kann er bearbeiten/löschen/hinzufügen, die Kalender der User D-G, mit den gleichen Berechtigungen freigegeben, kann er auch im Outlook verbinden und alle Termine einsehen, aber nicht bearbeiten/löschen/hinzufügen.


    So jetzt habe ich in der Exchange Shell nochmal die Berechtigungen geprüft, User A hat auf die Kalender der User B-G die Berechtigung "OWNER". Hab auch den Zugriff per Shell nochmals herunter- und wieder hochgestuft - keine Veränderung. Im OWA getestet, gleicher Fehler.
    Hat jemand eine Idee woran das liegen könnte?


    Sollte ich einfach mal CU2 einspielen, in der Hoffnung, dass ich hier auf einen Bug gestoßen bin oder lieber lassen solange der Fehler noch ungeklärt ist?


    Ich hoffe das ist halbwegs verständlich formuliert, bei Fragen fragen.


    Vielen Dank schon mal :)

    Mein Know-How in dem Umfeld ist mittelmäßig - es mangelt nicht an der Bedienung der Tools, eher bin ich nicht ganz firm, an welchen Stellen ich die falschen Einstellungen entfernen muss. Nein der SBS2003 ist schon seit Anfang 2015 weg. Es gibt einen Übergeordneten Exchange, der online erreichbar ist, aber keinen mehr an diesem Standort (jeder Standort ist seine eigene Verwaltung, deshalb praktisch unabhängige IT-Struktur).


    Gruß
    Kai


    PS: "Neu" deshalb, weil der Ausfall plan- und kompensierbar ist und somit minimal gehalten werden kann im vergleich zu einem "versehentlichen" Löschen im laufenden Betrieb.

    Hallo Ihr,


    bin mir nicht ganz sicher, wo dieser Eintrag platziert werden soll.
    Habe ein Kundennetz übernommen, nachdem sich der Kunde über den alten Dienstleister beschwert hat und unzufrieden ist. Ständig läuft irgendetwas nicht.
    Kurz zur Umgebung, zwei identische Server, auf dem einen läuft ein ESXi 5.5 mit 3 VMs, 2012 non-R2 als DC/Share/Print/DNS/DHCP-Server, also kurzum alles und noch zwei kleine VMs für Telefon und Zeiterfassung. Auf dem zweiten Server ist ein 2008R2 als "Backup Server" mit Veeam installiert, zusätzlich auch als FAX-Server, weil es der vorherige Dienstleister wohl nicht gebacken bekommen hat, das USB-Modem am ESXi korrekt einzurichten.
    Hier arbeiten ca. 20 User an ebenso vielen Arbeitsplätzen mit servergespeicherten Profilen. Da es eine Filiale einer größeren Organisation ist, wird inzwischen ein zentraler Exchange Server außer Haus mit verwendet.
    Die beiden neuen Server sind wohl Anfang 2015 installiert worden, ursprünglich sollten diese gespiegelt laufen, scheinbar hatte man aber niemanden dazu abgestellt, der im Stande war eine Replikation einzurichten..
    Jetzt zum eigentlichen Problem, nach etwas Fehlersuche und beseitigen einiger kleiner Fehler bin ich nach und nach auf die Ursache der vielen Fehler im Betrieb gestoßen. Gerade das Arbeiten mit Outlook funktioniert teilweise schlecht bis überhaupt nicht (will sich oft am nicht mehr vorhandenen SBS anmelden, obwohl auf den neuen Exchange konfiguriert), Netzlaufwerke fehlen immer wieder (DNS Fehler), die servergespeicherten Profile funktionieren nicht und sind bei einzelnen Usern bis zu 10mal in gemischten Versionständen vorhanden, eine an den ESXi angebundene USB 2.0 HDD mit fast 1TB uralter Daten wurde tagtäglich übers Netzwerk mit gesichert, keine einzige Management Software oder zugehörige Treiber installiert, usw. (könnte das endlos so fortführen).
    Scheinbar (ich war nicht dabei, dokumentiert wurde absolut überhaupt nichts, außer die Lizenzen) hat man die FSMO vom vorherigen SBS2003 auf den 2012er migriert. Jetzt habe ich mich mal durch den ADSI-Editor gewühlt und bin auf tonnenweise Einträge und Verweise auf den Exchange des SBS und auch auf den SBS selbst gestoßen. So existiert unter anderem noch eine System Mailbox, Kalender- und Kontakte-Shares liegen verwaist rum, MS Ex Schemas sind wohl alle noch vorhanden, in den GPOs sind Konfigurationen die auf den SBS zeigen hinterlegt, SBS login scripte sind noch eingebunden und aktiv - kurzum es wurde massiv geschlampt und ist vermutlich nur die Spitze des Eisbergs.


    So meine Master-Frage: Was tun?


    Eigentlich müsste ich die beiden Server platt machen und das System komplett neu aufbauen, außer den reinen Daten nichts vom alten System mitnehmen. Problem: kann ich auf keinen Fall machen...


    Hat jemand Ideen/Vorschläge? Vielleicht mal etwas ähnliches erlebt?



    PS Wer jetzt denkt das war irgendeine kleine IT-Hinterhof-Bastlerstube, leider nicht, das war einer der größten deutschen IT-Dienstleister. :(