Rocknrolla

Acha! Genau das meinte ich - es sieht zunächst anders aus als in der gpedit.msc und du beschrieben hattest. Jetzt mit "Bearbeiten" geht es natürlich. Vielen, vielen Dank Sunny61!

In der GPMC finde ich die Einstellung nicht! Ich weiß nicht wo ich suchen soll. :rolleyes:

Das weiß ich doch. Davon hatte ich im ersten Beitrag doch geschrieben. Siehe screenshot. Aber wo ändere ich die Werte in der GPMC.MSC ? Das finde ich nicht.

Ok, und wo da?

Hallo, ich wollte die Kontensperrungsschwelle auf 10 setzen, aber ich sehe gerade in den GPOs Computerkonfiguration/Sicherheitseinstellungen/Kontorichtlinien, daß dort die "Kontensperrungsschwelle" nicht konfigurierbar ist, da das entspr. Fenster und die Bedienelemente ausgegraut sind? Was muss ich tun um es zu aktivieren?

Danke, ich werde schauen. Allerdings hatte es bisher keine Probleme mit der Datenübertragung gegeben - ausser natürlich bei Hardwareproblemen. Ich denke aber, wir steigen auf JTL um.

Damit kenne ich mich nicht aus. Aber wenn du mir sagst wie, dann kann ich es versuchen. Zunächst habe ich mit Personalbackup 3x täglich Sicherung inkrementell und 3x die Woche voll eingerichtet. Nur für die Datenbankordner. BTW - ja es ist Access.db

Hallo, die scheinbare Rätsels Lösung - es war wahrscheinlich doch die Netzwerkkarte. Gestern habe ich eine PCI-E Netzwerkkarte eingebaut und die Server IP auf diese umgeschaltet. Es kamen dann nur noch Fehlermeldungen von unserer Datenbanksoftware "Faktura XP". Diese lautete (war immer die gleiche) sinngemäß "Keine Verbindung zur Datenbank... bla bla .. Wahrscheinlich existiert ein Netzwerkproblem.". Die Fehlermeldungen zu den Freigabenkonnektivitäten sind ausgeblieben. Das war zunächst nicht aufgefallen. Jetzt der Hit - die Faktura XP Fehlermeldung war falsch (!) Die Datenbank war beschädigt. Nach der Reparatur verschwanden ruckartig alle Probleme. Die Karte ist immer noch umgeschaltet und ich möchte das jetzt nicht ausprobieren ob der Fehler dann wieder erscheint. Wie wahrscheinlich ist, daß eine Datenbank die Freigaben auf allen Rechnern in einer Domäne lahmliegt auch wenn die Faktura Software nicht immer zugleich während des Fehlers verwendet wird? Praktisch Null - oder? Wahrscheinlicher ist, daß zwei Fehler gleichzeitig die Lösung unnötig verzögerten wobei der eine Fehler die Folge des anderen, aber nicht der Grund war. Vermutlich wurde die Datenbankverbindung beim zurückschreiben auf den Server unterbrochen und die DB dadurch beschädigt. Statt den Fehler in der DB zu melden, meldete die Warenwirtschaftsoftware aber lieber Netzwerkprobleme. Daher fiel mir gestern nicht sofort auf, dass der Verbindungsfehler behoben ist und nur ein anderer Fehler existiert. Es ist Kaspersky Small Office Security 3.

Die Karte ist es nicht. Habe es mit einer anderen Karte ausprobiert. Die Treiber sind lt. Windows Gerätemanager auf dem neuesten Stand.

Auch das hat nicht geholfen. Ich werde schauen ob vielleicht die Netzwerkkarte kaputt ist auf dem Server.

Ich habe jetzt mit netsh int ip reset resetlog.txt die NIC zurückgesetzt - kein Erfolg. Dann habe ich den Client aus der Domäne rausgenommen und wieder aufenommen - kein Erfolg. Verbundene Freigaben verlieren plötzlich kurzfristig die Verbindung - nichts läuft mehr. Ich schaue auf den letzten client, vermutlich wird dort das selbe sein.

Ja, es passiert auf jeden der betroffenen Rechner und dort auf jeden Profil. Die Freigaben waren schon immer per IP angebunden - ich denke nicht, daß es daran liegen kann. Edit Habe es ausprobiert. Daran liegt es nicht.

Nein, der Server war total ausgefallen. Es ging garnichts mehr. Replikation war nicht möglich. Es war der alte Name der Domäne in einem Fall (nicht verwendet stand daneben) und in den anderen Fällen waren es "Netzwerk 1" oder "Netzwerk 4" - vermutlich als die Rechner woanders angeschlossen waren. Es gibt keinen WINS Server. Die Freigaben wurden per IP angebunden - also in etwa '\\192.168.100.100\freigabename'. Ich durchsuche mal die Registry Edit So, ich habe es gefunden, gesichert dann gelöscht. Hat nicht geholfen. Nochmal das gleiche - gefunden, gesichert, gelöscht. Mit neuen Laufwerkbuchstaben verbunden - hat nicht geholfen!

Es ist kein Cardreader eingebaut. Die Rechner sind in einer Domäne. Vor kurzem wurde der Server ausgetauscht und neu aufgesetzt. Mit gleicher Domäne und gleichen Bentzern und Freigaben. Die clients wurden zuvor aus der alten Domäne rausgenommen und mit der neuen wieder neu verbunden. Der Fehler tauchte dann kurzzeitig auf einem der Rechner auf. Beim Versuch es zu beheben stieß ich im Netzwerk- und Freigabencenter auf eine Liste von älteren nicht mehr benötigten Netzwerke und löschte diese. Das verwendete Netzwerk ließ ich natürlich da, änderte jedoch den Namen in den Namen der Domäne. Nun aber ist der Fehler auf mehreren PCs aufgetaucht und ich werde das Gefühl nicht los, daß es damit zusammenhängt. @ Sunny61 Kannst du bitte erklären was du damit meinst?

Hallo, es gibt massive Probleme mit den Zugriff auf die Netzwlaufwerke. Es ist ein AD mit Windows SBS 2011 Server und 5 Clients. Auf einigen davon taucht immer wieder ein Fehler auf: "Der lokale Gerätename wird bereits verwendet" Zu diesem Thema fand ich das hier -> http://support.microsoft.com/kb/890413/de Dort steht: "Um das Problem zu beheben, entfernen Sie die vorhandene Netzwerkzuordnung. Erstellen Sie dann eine neue Netzwerkzuordnung für das freigegebene Laufwerk." Was ist mit der "Netzwerkzuordnung" gemeint? Ich habe die Netzlaufwerke entfernt und wieder neu verbunden, aber das half nicht. Also muss es was anderes sein. Im Netzwerk- und Freigabezentrum dort wo man die Netzwerke zusammenfassen oder löschen kann, habe ich nur ein Netzwerk in der Liste. Edit Ich habe jetzt das Netzlaufwerk gelöscht und zwar mittels net use X: /delete Doch in der Liste der Laufwerke im Explorer ist es immer noch da!

Bonjour! Auf einem SBS 2011 habe ich folgendes Problem. Es taucht immer wieder die Fehlermeldung Ereignis-ID 1105 (und dann auch noch 1827). Protokollname: Application Quelle: MSSQL$SBSMONITORING Datum: 03.01.2014 07:03:15 Ereignis-ID: 1105 Aufgabenkategorie:Server Ebene: Fehler Schlüsselwörter:Klassisch Benutzer: SYSTEM Computer: derServer.diedomäne.local Beschreibung: Speicherplatz für das 'dbo.EventLog'.'IDX_EventLog_DateOccurred'-Objekt in der SBSMonitoring-Datenbank konnte nicht belegt werden, da die Dateigruppe 'PRIMARY' voll ist. Speicherplatz kann durch Löschen nicht benötigter Dateien, Löschen von Objekten in der Dateigruppe, Hinzufügen von Dateien zur Dateigruppe oder Festlegen der automatischen Vergrößerung für vorhandene Dateien in der Dateigruppe gewonnen werden. Ereignis-XML: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="MSSQL$SBSMONITORING" /> <EventID Qualifiers="49152">1105</EventID> <Level>2</Level> <Task>2</Task> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2014-01-03T06:03:15.000000000Z" /> <EventRecordID>1504459</EventRecordID> <Channel>Application</Channel> <Computer>derServer.diedomäne.local</Computer> <Security UserID="S-1-5-18" /> </System> <EventData> <Data>dbo.EventLog</Data> <Data>.'IDX_EventLog_DateOccurred'</Data> <Data>SBSMonitoring</Data> <Data>PRIMARY</Data> <Binary>51040000110000001A0000004D0054002D005300450052005600450052002D0031005C005300420053004D004F004E00490054004F00520049004E00470000000E0000005300420053004D006F006E00690074006F00720069006E0067000000</Binary> </EventData> </Event> Ich versuchte daraufhin damit den Fehler zu beheben: http://blogs.technet.com/b/sbs/archive/2009/07/14/sbs-2008-console-may-take-too-long-to-display-alerts-and-security-statuses-display-not-available-or-crash.aspx Doch nach zig Minuten rödeln kam folgendes raus (siehe Screenshot). Jetzt bin ich mit meinem Latein am Ende.

Das will nicht klappen - er meldet mir folgendes. Ich habe gegoogelt und rausgefunden, dass der Server hier offenbar u.U. behaupten soll, andere Benutzer würden auf die Daten zugreifen, dann habe ich den Server neugestartet, es sind jedoch keine clients online und verbunden. Irgendwo hackts aber - er hat sich offenbar eine Datenverbindung gemerkt oder etwas anderes ist die Ursache. Weder Systemupdate, noch Aktualisiertung, noch eine Sicherung bzw. andere derartige Aufgaben sind aktiv. Zumindest habe ich keine festgestellt. Nach Neustart - weiterhin diese Fehlermeldung.

Es sind lokale Laufwerke auf dem Server. Ok - das mit den Umzug mithilfe des SBS Assistenten kenn ich nicht und habe den nie benutzt - wo finde ich den?

Hallo, ich möchte in einer SBS 2k11 Domäne die auf dem Server Laufwerk "E" im Ordner "profiles", gespeicherten Benutzerprofile (username & username.v2) auf Laufwerk "F" umziehen. Danach werden die Laufwerke umbenannt, so daß Laufwerk "F" zum Laufwerk "E" wird und Laufwerk "E" zum Laufwerk "G". Laufwerk "E" ist zu klein geworden, daher wird es nur noch für Ablage verwendet. Ich habe in der Vergangenheit allerdings festgestellt, dass oftmals Profile danach von den Benutzern nicht mehr genutzt werden können auch wenn der Laufwerksbuchstabe gleich ist. Oftmals funktionierten manche Zugriffe auf Dateien darin. Auch im Unterordner "AppData". Das lag daran, dass der Administrator (der Domänenadmin) keinen Zugriff auf die "v2" Verzeichnisse hatte. Als ich ihn dann zum Eigentümer machte, konnte ich zugreifen, jedoch machte es Schwierigkeiten für die eigentlichen Eigentümer und ließ sich das später oftmals nur mit viel Ärger umkehren, damit der Benutzer auch Zugriff auf alles wie vorher hat. Was muss ich beachten um möglichst sicher umzuziehen, damit die Benutzer danach ohne Probleme auf alle Daten und Einstellungen zugreifen können? Anbei - ich habe sehr viele Freigaben und benötige eine Möglichkeit all diese Freigaben mit den ganzen Zugriffsrechten und erlaubten Benutzern auf einmal auszulesen um so Zeit beim Durchsuchen jeder Freigabe und ihrer Sicherheitseinstellungen zu sparen. Gibt es ein Befehl oder Script, dass all diese Daten von einem Laufwer ausliest und in eine Textdatei als Ausgabe speichert o.ä. ?

Big Thx RobertWi.

Hallo! Ich habe ein kleines Problemchen. Es gibt mehrere Arbeitsstationen und eine e-Mailadresse, welche übergreifend für alle Mitarbeiter erreichbar sein soll. Aber jeweils der erste PC, welcher das Postfach auf dem Exchange 2010 abholt, lädt und leert die Exchange Mailbox, sodass für die anderen Rechner dieses Postfach leer ist. Natürlich möchten wir, dass auch andere die mails noch finden können. Sicherlich ist für die Experten hier im Forum ein bekanntes Problem. Es scheint jedoch nicht an den Clients zu legen - das konnte ich schon herausfinden.

Ich dachte, ich hätte auf Gegenfragen stets reagiert. Übrigens kann ich auch nur Stückchenweise den Fehler finden, denn sonst würde ich hier garnichts fragen müssen. Jetzt habe ich den Fehler ID 1004, Quelle IIS entdeckt (der erscheint nur nach einem Neustart des Servers, dann nicht mehr) und mit "netstat -ano" den Dienst "xitami Webserver" identifiziert. Der wird eindeutig von Supermicro SuperDoctor III ausgeführt und blockiert die Webseiten: - 127.0.0.1:80 - companyweb:80 - connect:80 Mal sehen was passiert wenn ich den automatischen Start abschalte und den Server reboote. So, das wärs. Es war also noch ein Webserver im Einsatz - von Supermicro eingeschleust. Die Exchange Management Console geht. Die Default Webseite zeigt weiterhin SuperDoctor III, aber ich kann mich da nicht mehr anmelden. Das ist natürlich nicht mehr so wichtig, Exchange ist wichtiger. test-servicehealth listet jetzt problemlos alle Rolen auf.

"Zusammengefasst" klingt aber sehr nach - keine Lust mehr oder keine Ahnung. Das wärs dann wohl...

Ich habe im Menü nur die "Windows PowerShell" und die "Exchange Management Shell". Die letztere hatte ich stets gestartet. Einen Eintrag über "Exchange PowerShell" gibt es hier nicht. Im Post #5 dieses Threads ist das der letzte screenshot (schwarzes Thumbnail) ------------------------- Die Default Webseite des IIS lässt sich nicht starten! Siehe Fehlermeldung. Wenn ich 127.0.0.1:80 aufrufe dann startet eine Seite des "SuperMicro SuperDoctor III Remote Management" - bei 127.0.0.1:443 kommt garnichts. Der "SuerDoctor III RM" ist ein Mainboard Management tool - ich habe da reingeschaut, aber keine Möglichkeit gefunden, daß er auf einem anderen Port bzw. anderer URL läuft.

Ich habe mich nur hier vertippt, denn ich habe das von einem Screenshot abgetippt den ich zuvor gemacht habe. Aber auch mit "test-servicehealth" klappts nicht. Default Seite muss ich schauen.