Wurzerl

Seit Jahren haben wir folgende Ordnerstruktur auf einem Windows Server 2008 R2 Fileserver: xLand 0_Alle x1_Region 0_Alle x1_Standort 0_Alle 1_Verwaltung 2_Intern x2_Standort Die Benutzer haben je nach Standort und Aufgabenbereich lesenden und schreiben Zugriff auf die Dateien und Verzeichnisse der Ordner "0_Alle" in jeder Ebene und der Ordner im Standort. Die Ordnerstruktur bis zum Standort ist jedoch vorgegeben und darf nicht geändert werden. Daher wurden auf den Strukturordnern, die mit einem "x" beginnen, für den Benutzer "Jeder" und "Nur diesen Ordner" folgendes "Verweigern" gesetzt: Dateien erstellen / Daten schreiben Ordner erstellen / Daten anhängen Unterordner und Dateien löschen Löschen Das Ziel sollte sein, daß diese Ordner weder verschoben noch gelöscht werden dürfen, die Benutzer ihre Ordner aber sehen und durchsuchen können. Jetzt kommt es zu folgendem Phänomen: Strukturordner mit "x" Niemand darf Ordner oder Dateien anlegen -> ok Können (von Benutzern) verschoben werden - > absolutes NOGO, kommt in letzter Zeit vor. Können (von Benutzern) gelöscht werden - > -"- -"- , konnte ich im Test jedoch durchführen, kam bisher vom Benutzer nicht vor. Strukturordnern der untersten Ebene In diesen dürfen Benutzer Dateien und Ordner erstellen, ändern und löschen. -> ok Die Struktur und Berechtigungen der Ablage wurden ursprünglich mit 2003 Servern erstellt und umgesetzt und vor 4 Jahren auf 2008 R2 implementiert. Erstmalig sind diese (hoffentlich unbeabsichtigten) Verschiebungen durch Benutzer im Frühjahr 2014 aufgetreten, gelöscht hat diese bis jetzt noch kein Benutzer. Wie kann ich das Ordnersystem (wieder) absichern? Verweigern war doch bis dato ein absolutes Recht, da konnte auch der "Herr Administrator" nichts daran ändern (außer er ändert die Rechte).

Wie schon erwähnt wurde, eine derartige Planung sollte mit einem Berater durchgeführt werden - das ist deren Brot, die machen solche Planungen mehrmals im Jahr. Mach Deiner GF klar, das auch der qualifizierteste KFZ-Mechaniker auf Zuruf kein neuen Fahrzeug im Alleingang entwerfen wird.

So flapsig würde ich mal meinen, daß für die Serverlandschaft (AD, File, Exchange, Sharepoint,SQL und Backup) dies die Mindestanforderungen sind: 2x HP DL 380 Gen8 mit je 128 GB RAM, darauf VMware vSphere 5 Standardlizenz 1x HP MSA 2040 (mind 6 LW bestückt) 1x HP MSL 2024 für 60 RDP-Sessions nochmal mind 2 x 380 Gen8 (MS Terminal Serverlizenzen nicht vergessen oder Virtual Desktop (Xen, VMware)) (da ist die Ausfallsicherheit für alle User nicht mehr gegeben) Bonne chance.

Dann ist jetzt Ruh´. :cool:

Danke - das hat das Problem der SQL-Server behoben, muss wohl nach der Installation des letzten WSUS-Updates erneut durchgeführt werden. Wobei es mir noch immer ein Rätsel ist, warum gerade die SQL-Server die Verbindung mit dem WSUS verweigerten - diese wurden erst nach der Installation der DC ausgerollt. Leider sind im WSUS noch immer die beiden Sprachpaketupdates sichtbar. Als Alternative bleibt mir nur, diese abzulehnen oder ewig mitzuschleifen. In den Logdateien befinden sich keine Hinweise auf die KB-Nummer oder den Text.

Trotzdem - oder gerade deswegen - installiere ich nur deutsche Versionen seit NT. Englische Version mit Citrix mit deutschprachigen Benutzern - da hast Grund zum Jubeln, wenn was nicht passt. Nebenbei - seit 2008 R2 ist das Wechseln eines Sprachpaketes nur mehr Kinderkram - hätt ich mir gewünscht, zur Zeiten der japanischen Windowsinstallationen.

Eigentlich bedeutet das, Du installierst eine Version und stellst die gewünschte Sprache ein. Generell installiere ich Deutsch, (damit´s spannend bleibt, gleich "de-AT") dann en-US als Sprachpaket, damit kann jederzeit die Umstellung auf (das amerikanisierte) Englisch erfolgen. Z. B. muß bei der Installation von SQL Servern je nach Sprachversion des SQL-Servers "de-DE" oder "en-US" die aktive Sprache sein.

IMHO ist die Lizenz nicht von der Sprache abhängig, sondern die Edition. Ändern der Anzeigesprache findest Du hier: http://windows.microsoft.com/de-at/windows-vista/change-the-display-language.

Hallo, folgendes Problem: WSUS Version 3.2.7600.262 auf Windows Server 2008 R2. Als WSUS-Clients sind mittlerweile auch Windows Server 2012 R2 installiert, diese werden jedoch nur als "Windows 2000 Datacenter Server" erkannt. Ist aber nicht das Problem, damit kann ich leben. Jedenfalls haben die "2012 R2" Server komische Eigenheiten, die ich gerne eliminieren möchte: Entweder werden die Server vom WSUS erkannt, jedoch tritt Fehler 1) auf, oder die Server melden Fehler 2). Fehler 1) Server werden mit Updates versorgt, lediglich zwei Updates bleiben im WSUS mit Genehmigung "Installieren" und Status "Nicht installiert": "Sprachpaket für Deutsch - Windows Server 2012 R2 - (KB2839636) [de-DE_LP]" "Sprachpaket für Englisch (USA) - Windows Server 2012 R2 - (KB2839636) [en_US_LP]" Bei den Clients tauchen diese Updates nicht auf, weder bei "Nach Updates suchen", "Updateverlauf anzeigen" oder "Ausgeblendete Updates anzeigen". Daher werden diese Updates im WSUS immer als "Erforderlich" angezeigt und der Installationstatus der Server bleibt auf "Warnung". Hätte ich gerne weg, ist etwas störend. Fehler 2) Betrifft "Windows Server 2012 R2" mit SQLServer 2012 Diese Server werden seit Monaten mit "Noch kein Bericht erstellt" angezeigt und ziehen daher auch keine Updates vom WSUS. Bug oder Feature, das ist hier die Frage. Onlineupdates können durchgeführt werden. Eigentlich möchte ich die Server gerne im WSUS haben. Merci schonmal, Wurzerl

Sorry, habe zu schnell gelesen, ist ja nur mehr im 90er Netz. Netzwerkkartentreiber entfernen und neu installieren, 200 Netz mit regedit lokalisieren, evt. (falls möglich) Netzwerkkarte entfernen, Neustart, Treiber säubern, Herunterfahren, Karte einbauen, oder andere Karte installieren.

Das kommt darauf an, was Du vorhast. Pro Service ein Partition, so setze ich das gerne um: File = Dateiablage f. Dokumente, etc. Home = Homeverzeichnis der Benutzer Profil = Profildaten

Da kann doch nur ein DHCP-Server im Spiel sein, vermute ich heftigst.

Prüfe, ob der entsprechende Benutzer auf dem Ordner Vollzugriff (Nur diesen Ordner und Besitzrechte hat. Das Konto "Ersteller-Besitzer" sollte Vollzugriff auf "Nur Unterordner und Dateien" haben. (Ordnereigenschaften, Sicherheit, Erweitert, Karteikarten Berechtigungen und Besitzer.) Offlinezwischenspeicherung: Rechtsklick auf den Ordner der Freigabe --> Eigenschaften --> Freigabe. Erweiterte Freigabe. Neues Fenster. Unten rechts Zwischenspeichern anklicken. Hier finden sich 4 Punkte, "Keine Dateien oder Programme aus dem freigegebenen Ordner verfügbar machen." auswählen.

Wir benutzen für diese Aufgabenstellung OLXcorporate. Über die AD-Felder werden Standort- und Benutzerdaten gesteuert.

Mal zu den Grundlagen: Lokale Gruppen Sieh Dir die Gruppentypen an. In der OU Builtin befinden sich (ausgenommen des "Herrn" Administrator) nur domänenlokale Gruppen. Diese OU und deren Inhalt sollte unangetastet bleiben. Der domänenlokalen Gruppe werden die Rechte, z.B. im Filesystem vergeben. Mitglieder können sein: domänenlokale, domänenglobale und universelle Gruppen. Jedoch können diese niemals Mitglieder einer domänenglobalen oder universellen Gruppe werden. Daher sind sie auch nicht sichtbar, wenn versucht wird, sie einer universellen oder globalen Gruppe als Mitglieder hinzuzufügen. Profilordner: Der Ordner selbst ist für Administratoren sichtbar, aber nicht der Inhalt. Der ist nur für den Benutzer sichtbar (und sollte es auch bleiben). Der Administrator kann andere Benutzer hinzufügen (damit übernimmt der Administrator auch den Besitz des Ordners und dessn Inhalt) - daher ist er danach auch durchsuchbar. Das AD und seine Struktur sind kein Geheimnis, sondern logisch aufgebaut. Ich empfehle Dir ein gründliches Studium mit guten Büchern desselben. Es gibt auch gute Kurse, die ein grundlegendes Verständnis für das AD vermitteln. Rechte von Benutzerordnern verändern ist ein heikles Thema, ein grundlegender Kurs im Datenschutzrecht ist auch nicht verkehrt. Sonst muß man möglicherweise für die Fehler von anderen einstehen. Unwissenheit schützt auch hier nicht vor Strafe.

In irgendeinem Adreßbuch müssen Deiner Beschreibung nach die Daten von "bei-spiel.de" auch vorhanden sein, da Du sie ja überprüfst. Im Zuge der Überprüfung werden diese dann durch "beispiel.de" ersetzt. In jedem Falle aber, wie von Günther empfohlen, den Cache (Autovervollständigen-Liste) leeren und die Adressbücher überprüfen (falls vorhanden).

Natürlich ist ein Benutzer Voraussetzung, die Credentials müssen im Mailclient dazu angegeben werden.

Danke für die Rückmeldung! :thumb1:

Tritt das Phänomen nur bei einer Adresse (Peter.Fischer) auf, oder auch bei anderen (z.B. Sabine.Meier)?

Dein Gefühl kann ich bestätigen, seit Anfang Oktober ist der Exchange Server zu einer Mimose geworden. Meist sind die Werte im Attribut "LegacyExchangeDN" im Benutzerobjekt der Verursacher, diese müssen jetzt anscheinend zwingend mit den Namen im Mail übereinstimmen. Heirat, Scheidung, Kontenübernahme, was jahrelang problemlos möglich war, braucht jetzt Eingriffe mit der AD-Karteikarte Attribut oder dem ADSI-Editor "Standardmäßiger Namenskontext [DC.dom.intern] - DC=dom, DC=intern, OU=User, CN=Benutzer". Nicht nur das, auch die Autovervollständigen-Liste von Outlook muß bei jedem Benutzer geleert, und auch die Globale Adressliste im Outlook unbedingt aktualisiert (aber bitte erst einen Tag später). Welche Wildsau das Exchangeteam geritten hat, oder ob sie von wilden Hunden gebissen wurden, wissen wir nicht, und werden es wahrscheinlich auch nicht erfahren. :cry: Ob sie sich dabei etwas gedacht haben, steht auch in den Sternen. :thumb2: Jedenfalls wieder ein Haufen Arbeit für die Fisch und wer ist wieder schuld, daß das Mail nicht geht: die IT, die *******n. :suspect:

Mit dem Account des Benutzers, bei dem der Fehler auftrat, ein Testmail über OWA versenden. Dann weiß man ob das Problem dem Outlook oder Exchange zuzuordnen ist.

Manchmal kommt es vor, daß die Adresse des Empfängers um die interne Domäne unserer Organisation erweitert wird. Auszug aus der Unzustellbarkeitsmail "Diagnoseinformationen für Administratoren: Generierender Server: EXCHGSRV01.unsere.intern IMCEAMAILTO-Vorname+2EName+40fremde+2Eorg@unsere.intern #550 5.4.4 ROUTING.NoConnectorForAddressType; unable to route for address type ## Ursprüngliche Nachrichtenkopfzeilen: Received: from EXCHGSRV02.unsere.intern ([10.100.2.14]) by exchgsrv01 ([10.100.2.15]) with mapi id 14.01.0421.002; Mon, 12 Nov 2012 15:15:04 +0100 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: binary From: "Nachname, Vorname" <vorname.nachname@unsere.org> To: "'Vorname.Nachname@fremde.org'" <IMCEAMAILTO-Vorname+2EName+40fremde+2Eorg@unsere.intern>" ExchgSrv02 = Mailbox ExchgSrv01 = CAS, HUB Falls es eine Erklärung und/oder einen Lösungsansatz gibt, bitte melden.

Theoretisch wäre das mit einer NAT-Regel möglich, würde davon aber abraten. Eine VPN-Verbindung zwischen Firewall und Client sollte das mindeste an Sicherheit sein. Dies sollte mit jeder halbwegs guten Firewall mit OpenVPN oder einem produktbasiertem Client möglich sein.

"Net use" setzt die Laufwerksbuchstaben, der erste Parameter steht für den gewünschten Buchstaben.

Egal, welche Lösung Du bevorzugst - verzichte nicht auf die SAN. Damit verzichtest Du schon im Vorfeld auf VMotion (und ist bei VMware 5.1 schon im Standard enthalten). Ich betreue z.B.: ein System mit 3 DL 380 G7, Intel Xeon X5650, 96 GB, mit SAN AX4 mit 10 TB Speicher, je 2 x Quadport GB Server Adapter. Pro Host laufen 16 - 18 VM´s, darunter produktive Exchange 2010 und SQL Server 2008 für 500 User. Das System läuft seit zwei Jahren klaglos und unauffällig.