Gulp

Wie sehen denn die Einstellungen des virtuellen Speichers (der ja laut Event Protokoll defragmentiert) aus? Da dürfte eine feste Grösse der Auslagerungsdatei helfen. Grüsse Gulp

Bei diesen Problemen mit dem Windows Installer hat sich das Microsoft Installer Cleanup Utility oft bewährt. Infos und Download HIER Unter Umständen kommt man allerdings nicht umhin, die entsprechenden Verursacher neu zu installieren. Da der Installer meistens allerdings auch eine Repair Option bietet, ist es manchmal ausreichend die Software zu reparieren. Grüsse Gulp

Hallo Nicole, da gibt es zwei Möglichkeiten: Lösung 1: Leeres SA Passwort (nicht empfehlenswert) Dazu muss das Setup mit folgendem Parameter ausgeführt werden "BLANKSAPWD=1" (ohne die "). zB Start --> Ausführen --> [Pfad zur Setup]\setup.exe blanksapwd=1 Lösung 2: Passwort für SA bei der Installation setzen (deutlich besser) Folgender Parameter erledigt das: SAPWD="Sicheres Kennwort" Einige wichtige Setup Parameter von MSDE: SAPWD="SicheresKennwort" Gibt ein sicheres Kennwort an, das dem Administratorbenutzernamen sa zugewiesen werden soll. INSTANCENAME="Instanzname" Gibt den Namen der Instanz an. Wenn INSTANCENAME nicht angegeben wird, installiert das Setupprogramm eine Standardinstanz. Zum Anpassen einer Installation werden darüber hinaus häufig die folgenden Parameter verwendet: DISABLENETWORKPROTOCOLS=n Gibt an, ob die Instanz Netzwerkverbindungen von Anwendungen zulässt, die auf anderen Computern ausgeführt werden. Standardmäßig, bzw. wenn Sie DISABLENTWORKPROTOCOL=1 angeben, konfiguriert das Setupprogramm die Instanz so, dass Netzwerkverbindungen nicht zugelassen werden. Geben Sie DISABLENETWORKPROTOCOLS=0 an, um Netzwerkverbindungen zu ermöglichen. SECURITYMODE=SQL Gibt an, dass die Instanz im gemischten Modus installiert werden soll, in dem die Instanz Benutzernamen sowohl der Windows-Authentifizierung als auch der SQL-Authentifizierung unterstützt. DATADIR="Pfad_zum_Datenordner" Gibt den Ordner an, in dem das Setupprogramm die Systemdatenbanken, Fehlerprotokolle und Installationsskripts installiert. Der für Pfad_zum_Datenordner angegebene Wert muss mit einem umgekehrten Schrägstrich (\) enden. Bei einer Standardinstanz fügt das Setupprogramm MSSQL\ an den angegebenen Wert an. Bei einer benannten Instanz fügt das Setupprogramm MSSQL$Instanzname\ an, wobei Instanzname dem Wert entspricht, der im Parameter INSTANCENAME angegeben wurde. Das Setupprogramm erstellt drei Ordner am angegebenen Speicherort: einen Datenordner, einen Protokollordner und einen Skriptordner. TARGETDIR="Pfad_zum_Ordner_für_ausführbare_Dateien" Gibt den Ordner an, in dem das Setupprogramm die ausführbaren Dateien von MSDE 2000 installiert. Der für Pfad_zum_Ordner_für_ausführbare_Dateien angegebene Wert muss mit einem umgekehrten Schrägstrich (\) enden. Bei einer Standardinstanz fügt das Setupprogramm MSSQL\Binn an den angegebenen Wert an. Bei einer benannten Instanz fügt das Setupprogramm MSSQL$Instanzname\Binn an, wobei Instanzname dem Wert entspricht, der im Parameter INSTANCENAME angegeben wurde. Grüsse Gulp

Vergiss es ... Die einzigen mir bekannte Möglichkeiten sind die von Dir genannten (DFÜ, GPO und natürlich die 'normale' Anmeldung an der Domäne). Diesen Fall hatte ich auch schon und fand keine Lösung. Dort behalf man sich mit einem Anruf bei der EDV, die dann manuell ein neues Passwort erstellte (natürlich mit Passwort-Generator, da ja komplexe Passwörter im Amiland auch sehr populär sind - 90% der dortigen User schreiben die dann auf und kleben die Passwörter inkl. Username auf das Notebook - sehr sinnig! Da fragt man sich ob die 'normalen User' im Amiland auch so handeln und die strengen Policies der Ami-Konzerne stünden wieder in einem ganz anderen Licht.) Grüsse Gulp

Das halte ich aber für ein Gerücht .... Ich habe mehrere GMX Konten, die ich schon seit Jahren ohne SSL abrufe. Lediglich ein SMTP before POP ist da von Nöten und das kannst Du in den Konteneigenschaften bei Postausgangserver durch das eintragen Deiner Kontodaten erreichen. Grüsse Gulp

Auf SMB Freigaben (nix anderes sind Windows Freigaben) kommt man in Unix/Linux immer mit der Eingabe smb:///Freigabe im Dateibrowser .... Grüsse Gulp

Hallihallo, komisch, dass die von Symantec damit nix anfangen können, aber was soll's. Norton kann keine E-Mail Konten mit SSL scannen. Entweder schaltest Du die SSL Verschlüsselung in Deinem(n) E-Mail Konto(en) aus oder Du deaktivierst das Scannen der E-Mails (nicht unbedingt empfehlenswert). Grüsse Gulp

Hat in der Regel nix mit dem Programm Nero oder dem Brenner zu tun .... Beim Forum in CHIP.de (man staune - ich halte CHIP ja mittlerweile für eine Art Bildzeitung für Computerkram - aber egal, wenn's hilft ..... ;-) ) gibt's nen recht ausführlichen Thread dazu: CHIP Forum Grüsse Gulp

Sorry, ich sehe bei Deinen Links nicht eine Enterprise/Corporate Version ..... nur Consumer Produkte. ..... as I said before ..... Grüsse Gulp

Also ich habe hier McAfee ViruScan Enterprise 8.0 und Symantec AntiVirus Corporate 9.0 im Einsatz und kann über beide nicht klagen ... TrendMicro ist auch eine feine Lösung, vor allem lassen sich alle Einzelkomponenten (ServerProtect, OfficeScan, VirusWall, ScanMail) wunderbar über TCM zentral managen. Nur am Rande ... die Symantec Corporate Version unterscheidet sich mehr als deutlich von NAV und hat auch nicht den Ressourcenverbrauch von NAV. In 'aktuellen' Tests habe ich noch keine Enterprise Version entdecken könne, weder von Symantec noch von anderen Herstellern. Grüsse Gulp

Klar brauchst Du eine Anmeldung, ragazzomusic schreibt aber auch, dass sich dieser Admin Account an Workstations (auch an der Domain) anmelden kann. Damit kann er auch die MMC nutzen. Ob's dann von den Rechten passt wird sich spätestens beim Änderungsversuch zeigen. Grüsse

Naja, eine Erfolgsgarantie gibt es nicht unbedingt, denn wenn Du den Admin (unabsichtlich) schon so beschränkt hast, dass eine Anmeldung an der Konsole des Servers nicht mehr funktioniert, kann es schliesslich auch sein, dass Dir der Zugriff für Änderungen am ADS genauso 'hopsgegangen' ist. Darum tut es immer gut einen 'Ersatz-Admin' im ADS zu plazieren, mit dem kann man wenigstens sowas rückgängig machen. Grüsse Gulp

Bääääh, wieder nur nen Apfel als Mittagessen ..... komisch, ich müsste irgendwie auch mal abnehmen bei dem Essenpensum, aber ich wiege immer noch genauso viel wie sonst. Nun ja, heute abend gibt's auf jeden Fall was Warmes .... *freu* Grüsse Gulp

Moin, moin ... Ich fange heute mal mit Cappuccino an ... Kaffee is alle .... *cappuindieRundestell* Grüsse Gulp

Ein DC mit aktiviertem ADS schaltet die lokale Kontenverwaltung ab, daher sind bei DC's generell keine Anmeldungen mit lokalen Konten möglich. Anders sieht es für den DomänenAdmin aus, der darf sich natürlich anmelden, es sei denn da hat jemand an Richtlinien oder am Account gedreht. Nicht-Admins dürfen sich standardmässig ebenfalls nicht an der Serverkonsole anmelden, sondern ggfs nur an einer Teminalsession. Die genannte Fehlermeldung deutet erstmal auf einen Anmeldeversuch mit einem Nicht-Admin an der Serverkonsole hin. Grüsse Gulp

Auch wenn Vertrauensstellungen zwischen Domänen bestehen, sind mehrere Domänen im Anmeldedialog auswählbar. Ich traue der Geschichte mit dem Hinzufügen eines Hosts an mehreren Domänen immer noch nicht so recht, auch wenn's zu funktionieren scheint. Grüsse Gulp

Dass ein DC keine Computer-SID hat sagte ich doch gar nicht! Er hat eine, aber eben eine im Active Directory. Nicht-DC's haben aber zwei Computer-SID's, eine lokale (die der DC nicht hat) und eine im Active Directory. Diese beiden unterscheiden sich, wie Du trefflich bemerkt hast, weil die lokale Computer-SID des Nicht-DC bei der Installation zufällig erstellt wird. Die Zweite Computer-SID, ich will sie mal Domänen-Computer-SID nennen (entspricht dem Domänen Computerkonto), wird beim Domänenbeitritt erstellt und auch im AD gespeichert. Nachzulesen in Well-known security identifiers in Windows operating systems @blub: Sorry, da hab ich mich echt verguckt, es ist der Infrastructure-Master, der nicht auf den GC gehört. siehe FSMO placement and optimization on Active Directory domain controllers Mit verspäteter Replikation meinte ich unter anderem dieses hier (manchmal sollte ich mir wirklich Gedanken über eindeutige Ausdrücke machen ;) ) : Windows 2000 SID filtering prevents the replication of schema naming contexts and of configuration naming contexts So nun noch ein wenig 'Bettlektüre' zu den SID's: How Security Identifiers Work Grüsse Gulp

Hehe, wieder mal mein Lieblingsthema SID's: Ein Domain Controller zeigt lediglich die Domain SID an. Diese muss bei allen Domain Controllern identisch sein. Die lokale SID, die bei der Installation vergeben wird, wird bei DC's nach dcpromo nicht mehr verwendet. (Versuche mal bei einem DC zB einen lokalen Benutzer anzulegen - für lokale Objekte wird die eben diese lokale SID verwendet, für Domänen Objekte eben die omain SID + den aktuellen Relative ID Pool, den der Poolmaster verwaltet.) DC's unterscheiden sich selbst anhand der DC-Computerkonten im Directory. Bei den SID's geht's reichlich kompliziert zu. Es gibt lokale SID's, die in Arbeitsgruppen die grosse Rolle spielen. Lokale SID's haben alle Workstations, egal ob diese in einer Domain oder nur in einer Arbeitsgruppe sind. Diese lokalen SID's werden unter anderem für lokale Anmeldungen benutzt. (In einem domänenbasierten Netzwerk hat zB auch der lokale Workstation Admin administrativen Zugriff über das Netzwerk auf die Workstation, aber auch der Domänenadmin.) Es gibt Domänen SID's. DC's haben diese Domänen SID und hängen eine relative ID (RID) dran, um die Eindeutigkeit der ID zu gewährleisten. Dieser RID Pool wird von einem DC verwaltet (wie Betriebsmasterrolle, etc). Domaincontroller werden standardmässig ihrer lokalen Kontenverwaltung nach dcpromo beraubt, daher spielt die lokale SID für DC's (fast) keine Rolle mehr. Günter's Link verweist auch 'nur' auf duplicate SID's in der SAM, also bereits SID's aus Domänen. Die lokalen SID's sind da aussen vor. Tatsächlich kann es auch im Domänenumfeld in manchen ungünstigen Konstellationen zu doppelten Domänen-SID's kommen (Thema: RID-Master auf GlobalCatalogue DC, verspätete Replikation bei Vetrauensstellungen und mehr), die man bei MS mit Hilfe von SIDFiltering in den Griff bekommen kann. (MS KB 315062 ) Grüsse Gulp

Da gibts nen einfachen Trick: Druckwarteschlange in den Diensten beenden und anschliessend Treiber deinstallieren, Druckwarteschlange neu starten, fertig. Grüsse Gulp

Stimmt die Rechner SID bleibt gleich, ist ja auch eine lokale SID, die im ADS keine Rolle spielt. Wohl aber in der Kommunikation von Client zu Client (auch das solls in Domänen ja geben) ... Hier ein Auszug aus http://www.sysinternals.com/Utilities/NewSid.html (den Edgar abe sicher schon kennt ;) ): The SID Duplication Problem The problem with cloning is that it is only supported by Microsoft in a very limited sense. Microsoft has stated that cloning systems is only supported if it is done before the GUI portion of Windows Setup has been reached. When the install reaches this point the computer is assigned a name and a unique computer SID. If a system is cloned after this step the cloned machines will all have identical computer SIDs. Note that just changing the computer name or adding the computer to a different domain does not change the computer SID. Changing the name or domain only changes the domain SID if the computer was previously associated with a domain. To understand the problem that cloning can cause, it is first necessary to understand how individual local accounts on a computer are assigned SIDs. The SIDs of local accounts consist of the computer's SID and an appended RID (Relative Identifier). The RID starts at a fixed value, and is increased by one for each account created. This means that the second account on one computer, for example, will be given the same RID as the second account on a clone. The result is that both accounts have the same SID. Duplicate SIDs aren't an issue in a Domain-based environment since domain accounts have SID's based on the Domain SID. But, according to Microsoft Knowledge Base article Q162001, "Do Not Disk Duplicate Installed Versions of Windows NT", in a Workgroup environment security is based on local account SIDs. Thus, if two computers have users with the same SID, the Workgroup will not be able to distinguish between the users. All resources, including files and Registry keys, that one user has access to, the other will as well. Another instance where duplicate SIDs can cause problems is where there is removable media formated with NTFS, and local account security attributes are applied to files and directories. If such a media is moved to a different computer that has the same SID, then local accounts that otherwise would not be able to access the files might be able to if their account IDs happened to match those in the security attributes. This is not be possible if computers have different SIDs. Wenn ich mich recht entsinne wird die SID des Computerkontos in einer Domäne aber mit Hilfe der lokalen Computer SID generiert, wobei zwar nicht die komplette lokale SID herhalten muss, schliesslich muss ja auch zumindest ein Teil der Domänen-SID im Computerkonto hinterlegt sein, damit man den Rechner als Teil der Domäne identifizieren kann. Ich muss gleich mal gucken ob es zwischen der SID eines Computerkontos in einer Domäne und der lokalen Computer-SID Gemeinsamkeiten gibt. Grüsse Gulp

Hmm... sowas hab ich auch schon mal probiert und dann ne dicke Fehlermeldung bekommen. Ausserdem wage ich zu bezweifeln, dass dies in einer Produktiv-Umgebung zB mit GPO's, differenzierter File-Security und Netz-Security, Datenbanken und Drittanbietersoftware wirklich reibungslos funzt. Naja, ich lass mir gerne auch das Gegenteil beweisen. Grüsse Gulp

Moin, moin ... ... ein neuer Tag beginnt. Kaffee ist schon mal anwesend, so wie ich. Heiss is der Kaffee auch. Schmecken tut er nicht wirklich, wer hat das gebraut, der Azubi oder was? Hier liegen noch ein paar Kitkat Riegel neben dem Linux Server *indieRundewerf* .... Am Dienstag wird ein ein Server zum neuen DC hochgestuft *freu* und dann kann ich endlich die alte Samba Domäne wegwerfen. Wird zwar noch einen Rattenschwanz an Clientanpassungen nach sich ziehen, aber da kann ich wieder ein paar User gängeln *diabolischgrins*. Möge es noch viele Dienstage wie diesen geben! :D Grüsse Gulp

Ging mir auch schon so und das lief auch so cirka 1 Jahr problemlos. Dann gings aber los mit Problemen, Rechner konnten nicht mehr in die Domäne, Anmeldeprobleme, Synchronisationsprobleme mit Profilen, Zugriffsprobleme auf Freigaben und und und ... Das Ganze war eine NT 4 Domäne mit NT 4 Clients und wurde ständig mit Rechnern erweitert. Komischerweise waren diese Phänomene weg, als ich dann mit NewSID alle Kisten mit neuen SID's versorgt hatte. Bei W2K/W2K3 kriegen durch die Verwendung des ADS aber auch mehr Objekte SID's, als bei NT (weils auch mehr Objekte gibt), daher spielt die SID auch eine wichtigere Rolle. Trotzdem fallen die Probleme oft 'nur' in speziellen Fällen und Konstellationen auf. Grüsse Gulp

Das bekommt man doch ganz einfach mit dem Process Explorer von sysinternals raus. Ausserdem lässt sich damit gezielt nach dem geöffneten Handle suchen und dieses Handle kann auch damit geschlossen werden. Danach ist ein löschen der Datei problemlos möglich. Und das in der Regel ohne Neustart ..... Grüsse Gulp

Der Rechnername spielt da eine eher untergeordnete Rolle. Jedes Objekt im ADS (so auch Computerkonten) hat eine eindeutige SID (Security Identifier), die sich auch zwischen Domänen unterscheidet. Da sich die Kombination von Computer SID und Domänen SID von Client A und Client B unterscheiden wird schon beim lokalen Authentifizierungsversuch gemerkt, dass hier was nicht stimmt und da ruft der Client den DC zur Hilfe, vereinfacht ausgedrückt. Grüsse Gulp