Friesenjunge

Stimmt, das wäre eine Möglichkeit, ist aber in dieser Situation, da der Massenimport nur einmal erfolgen soll, nicht notwendig. @Daniel: OK, ist angekommen ;)

Erstmal Danke an alle! @Daniel und h-d.neuenfeldt: In mehreren Microsoft-Quellen habe ich gelesen, dass die CSV-Datei mit den zu importierenden Userdaten in UTF-8 gespeichert werden muss. Bei Powershell-Scripten ist es sogar so, dass UTF-8 mit aktiviertem BOM zum Speichern des Scriptes verwendet werden muss. Die Daten werden ja korrekt gelesen. @RHaneberg: Ich hatte es beim Path sowohl mit, als auch ohne Anführungszeichen versucht. bei beiden Varianten kommt es zu der Fehlermeldung. Mit den Passwörtern ist es so eine Sache. Auf der einen Seite ist es ja komfortabel, die Passwörter in der CSV mit zu übergeben. Man kann dann im Zuge einer Migration (dafür ist das gedacht...) aus der CSV heraus einen per Serienbrief einen "Kennwortbrief" für die User erstellen. Der Tipp zu dem Blogbeitrag ist sehr interessant, da hier die Möglichkeit beschrieben ist, die Klartextpasswörter auch im Massenimport in einen SecureString zu konvertieren. Ich teste das aus und melde mich wieder. Es ist auch nicht wirklich "kriegsentscheidend", ob ich die User direkt in der korrekten OU erstellt wird, oder zunächst im Container "Users" landet. Die OU wäre halt eine separate namens "Bulk-Import" gewesen, dort hätte ich alle auf einem Schwung gesehen und bei Bedarf manuell verschoben.

Sorry, habe im Nachhinein den Beitrag editiert und die Fehlermeldung Fett und Kursiv gesetzt und danach hat der Board-Editor diesen HTML-Schlunz reingeschrieben... Werde mich gleich nochmal dranmachen... Done, HTML-Code entfernt. Vielleicht hat die Boardware ja ein Prob mit aktuellem IE? Ha! bin einen kleinen Schritt weiter: Habe nun in der CSV die Spalte "Path" weggelassen. Dort hatte ich eingetragen: "CN=Thorsten Test, OU=Bulk-Insert,OU=Benutzer_Standort_01,OU=Benutzerkonten,DC=unsere-domain,DC=local" Nun klappte es. Allerding landen erwartungsgemäß die neu angelegten User nun in dem Standard-Container "Users"... Mein Ziel war eigentlich, die user direkt in einer bestimmten OU anzulegen.

Moin Community! Habe folgenden Artikel ( http://technet.microsoft.com/de-de/magazine/ee914610.aspx ) gelesen und wollte es in unserer Testumgebung gleich mal ausprobieren. Erstmal die passende CSV-Datei (in UTF-8 - wichtig!) erstellt, mit folgenden Spalten: name,UserPrincipalName,SamAccountName,displayname,givenname,surname,Office,Department,StreetAddress,PostalCode,City,Title,OfficePhone,Fax,Company,Path,accountpassword,enabled,ChangePasswordAtLogon: Nun habe ich in der Powershell (mit AD-Modul) den folgenden Befehl, wie im Artikel beschrieben, eingegeben und abgeschickt: So weit, so gut. Nun schmeit mir die Powershell aber für jeden anzulegenden User einen Fehler aus, mit dem ich nicht so recht was anfangen kann: +CategoryInfo: Object not found: (Probi Müller...ermany, DC=Local:String) [New-ADUser], ADIdentityNotFoundException +FullyQualifiedErrorID: Verzeichnisobjekt nicht gefunden, Microsoft.ActiveDirectory.Management.Commands.NewADUser Angemeldet bin ich, ich bin in der Gruppe der Domänenadministratoren. Die angegebene OU, die ich mit "Path" übergebe, sind definitiv vorhanden. Wo liegt mein (Denk?)Fehler? Falls Ihr noch weitere Infos braucht, liefere ich sie gerne nach. Danke! Euer Friesenjunge

Danke Tesso, der zweite Link hat mich auf den richtigen Weg gebracht. Ich habe das jetzt mal so eingestellt, dass gar kein RTF verwendet werden soll und die betroffenen Personen gebeten, es noch einmal zu testen. Ich gebe Euch Bescheid, ob es etwas gebracht hat. Bis dahin erst mal... [EDIT] So, wie versprochen gibt's nun meine Rückmeldung: Ich habe an folgender Stelle im Exchange System Manager die Einstellungen verändert: <First Organisation (Exhange)> - <Globale Einstellungen> - <Internet Nachrichtenformate> - <default (*)> --> Eigenschaften, Registerkarte "Nachrichtenformat", Abschnitt "Nachrichteninhalt", hier unter "MIME" auf "Nachrichtentext als unformatierter Text" umgestellt Danach wurden von allen Clients wieder Anhänge korrekt versandt. [/EDIT] Danke an Tesso, der an dieser Stelle den entscheidenden Tipp gegeben hat!

Ok, dann muss es wohl so sein. Ich kann die Datei (NK2, Stream_Autocomplete_<xyz123>.dat) ja vorher sichern, falls der Schritt nicht helfen sollte... Evtl. mit entsprechendem Tool vorher in CSV exportieren, und nachher re-importieren... Danke, Sunny, ich teste es mal ;-)

@tesso: Danke Trotzdem ;) Weiß das evtl. jemand anders?

Danke schon mal. Wo muss ich da im Exchange System Manager schauen? Oder ggf. im lokalen Outlook (Kontaktoptionen?) Das wäre extrem ätzend. Unsere User sind hier sehr empfindlich, wenn ihnen der Nicknamecache genommen wird. Würde es ggf. ausreichen, die Einträge der betroffenen Empfänger rauszulöschen?

Moin zusammen, wir haben hier seit ein paar Tagen auf unserem Exchange ein paar seltsame Phänomene: Exchange sendet gar keine Anhänge mit. Exchange sendet nicht den eigentlichen Anhang, sondern eine winmail.dat. Umgebung: Exchange: Windows Server 2003 R2 Standard SP2 Exchange Server 2003 Enterprise (Version 6.5 Build 7638.2 SP2) Mehrere Datenbanken (6 Postfachdatenbanken und eine für Öffentliche Ordner) Clients: OS: Windows XP Professional SP3 und Windows 7 Professional SP1 Office: 2003, 2007 und 2010 Oben genannte Phänomene treten in Einzelfällen unter der Kombination XP/Office 2003/2007/2010 Unter Windows 7 und Office 2010 ist es bisher nie aufgetreten. Interessanterweise ist das Verhalten nicht generell zu beobachten. Bitte ich eine betroffene Person, die entsprechende E-Mail an meine private Adresse zu senden, kann ich alle Anhänge ordnungsgemäß sehen und öffnen. Gibt es eine Möglichkeit, zentral auf dem Exchange festzulegen, dass E-Mails "normal" versendet werden? Auf den Clients habe ich im Prinzip schon alle Möglichkeiten durchgespielt (Format RTF, Text und HTML), die ich im Internet schon als Lösungsansätze gefunden habe. Es ist schon irgendwie schlecht, wenn Kunden keine Angebote, Auftragsbestätigungen etc. öffnen können... Wer hat das Problem schon mal gehabt und weiß, mich zumindest auf den richtigen Weg zu bringen, manchmal sieht man den Wald ja vor Bäumen nicht. Bin im Vorfeld schon für jeden konstruktiven Tip dankbar! :) Euer Friesenjunge

Erstmal noch Dank an alle, die sich beteiligt haben! @lefg: Ich habe gerade mit meinem (Systemadministrator-) Kollegen des anderen Standortes gesprochen, da er gerade bei uns zu Gast ist. Wir sind beide der Meinung, dass die "Befindlichkeiten" eigentlich eher aus dem Bauch heraus kommen und keine sachliche Grundlage haben. Eine klare Verteilung der Zuständigkeiten, hohe Disziplin und Absprache im Handeln und das inzwischen sehr hohe persönliche Vertrauen werden uns das Eindomänenmodell als klare Empfehlung einfach machen. Abgesehen vom höheren technischen Aufwand (beim Mehrdomänenmodell) sehen wir die Vorteile ganz klar darin, dass wir uns in Stoßzeiten problemlos gegenseitig aushelfen können. Morgen sehen wir mehr, da stellen wir den IT-Leitern der beiden Standorte unser Grobkonzept vor. Wenn dann die Entscheidung getroffen ist, geht es an die konkrete, technische und organisatorische Planung.

Ach, die "Befindlichkeiten" sind eigentlich Kinderkram. Nichts, was man nicht durch konkrete Absprachen und "Zugewiesener Objektverwaltung" hinbekäme. :cool: Ich denke, das gibt es bei allen Fusionen, bei denen aus Konkurrenten plötzlich eine große, glückliche Familie wird :wink2: ... Nur, dass das bei uns inzwischen 10 Jahre her ist und es endlich Zeit wird, die IT zu konsolidieren.

@lefg: Gegenfrage: Warum? Welche Vorteile siehst Du beim Eindomänenmodell gegenüber dem Mehrdomänenmodell? Ich selbst tendiere eigentlich zum Mehrdomänenmodell, aufgrund der Tatsache, dass es "Befindlichkeiten" gibt, die beim Mehrdomänenmodell ausgeräumt wären. Rein technisch sehe ich es jedoch wie Du, "Mach es einfach - und dann mach es einfach!" :-) Es gibt ja auch die Möglichkeit, den einzelnen IT-Abteilungen die Objektverwaltung an der eigenen OU zuzuweisen. Somit könnte jeder seine eigenen User & Co. pflegen, die Struktur wäre aber trotzdem flach.

Moin zusammen, zwei Standorte sollen nach einer Fusion IT-technisch zusammengefasst werden. Renaming der einen AD und Migration der anderen in die Rename'te scheidet aus. Nun stehen zwei Grobkonzepte zur Diskussion an: Leere Gesamtstruktur ("company.local") anlegen, und die einzelnen Standorte als Subdomain (standortA.company.local, standortB.company.local) erstellen. Eine neue Gesamtstruktur ("company.local") erstellen, und beide Standorte direkt hier pflegen (User, OUs, etc. ...) Ziel ist eindeutig, dass sich Benutzer aus beiden Standorten jeweils physisch auch im anderen Standort mit ihren Credentials anmelden können, jeder User darf nur einmal angelegt sein. Ferner sollen standortübergreifend Ressourcen dem anderen Standort zur Verfügung stehen. Exchange (2010 Enterprise) kommt dann auch noch ins Spiel. Sind mit beiden Konzepten die o.g. Vorgaben erfüllbar? Was würdet Ihr empfehlen. Ich habe zwar einen Favoriten, möchte aber Eure Meinungen unverfälscht hören/lesen. Vielen Dank schon mal! Euer Friesenjunge

Danke, Nils! Ich habe gehofft, dass Du oder Norbert sich dazu äußern ;) . Und die Antwort als solche gefällt mir auch gut. Meine Idee war von Anfang an, eine neue Gesamtstruktur zu bilden, in denen dann die einzelnen Standorte vereint werden. Die einzelnen IT-Abteilungen kann man dann autark über die Delegierung bestehen lassen, sodass jeder noch seine eigenen User und Hosts pflegen kann. Soll nicht heißen, dass ich Zahnis Antwort nicht zu schätzen weiß :D , auch Dir gilt mein Dank! Viele Grüße Friesenjunge

Moin zusammen, Aufgrund einer Firmenfusion sollen zwei AD-Strukturen zusammengelegt werden. Um den "Burgfrieden" zu wahren, soll die Domain, in die der andere Standort hineinmigriert werden soll, einen neutralen Namen erhalten. Bisher enthält der Domainname den alten Firmennamen. Zur Umgebung: Die umzubenennende Domäne hat drei DCs und mehrere Memberserver. Ein DC ist ein physikalischer Server ("Blech"), die anderen beiden sind virtuell. Die Memberserver sind alle virtuell. Der Exchange ist ein 2003er Enterprise, er läuft nicht im Cluster. Es existieren ca. 165 Clientsysteme, allesamt XP Pro und 7, Vista ist nicht im Einsatz. Im AD gibt es sowohl bei den Usern, als auch bei den Computern noch einige Karteileichen. Die Frage: Basierend auf den entsprechenden Artikel auf FAQ-o-matic.net von Mark Heitbrink haben wir einen "Schlachtplan" entwickelt und einen externen Dienstleister hinzugezogen Dieser erklärte uns gegenüber, dass er die Umbenennung der Umgebung als sehr risikoreich einschätzt. Er habe zwar in kleineren Umgebungen, die zudem nicht so historisch gewachsen seien, schon etliche Umbenennungen erfolgreich durchgeführt. In unserem Fall rate er jedoch deutlich davon ab. Wie schätzt Ihr das ein? Danke für Eure Meinungen! Viele Grüße Euer Friesenjunge

Richtig ;) Und selbstverständlich stelle ich hier eine Lösung ein, wenn ich sie gefunden habe, das ist doch das Wesen eines Forums, oder? Nur so haben andere mit einem ähnlich gelagerten Problem auch etwas davon ... Viele Grüße Friesenjunge

Sorry für die verspätete Antwort, Norbert ;-) Also, jemand hatte im virtuellen SMTP-Server das Relaying deaktiviert. Fehler behoben, die IP-Adresse unserer Barracuda eingetragen, und es geht wieder. Und ja, "Domain.tld" steht für die im Exchange konfigurierte SMTP-Domain, halt nur forengerecht anonymisiert ;-) Danke für Deine Hilfe, oder zumindest für den Versuch!

Liebe Mitstreiter, habe hier ein seltsames Phänomen: Der Exchange nimmt über SMTP keine Nachrichten mehr an. Verbinde ich mich über Putty auf Port 25, komme ich bis zu RCPT TO: postfach [ät] domain.tld, hier bricht er ab mit: 550 5.7.1 Unable to relay for postfach [ät] domain.tld Wer kann mir helfen? DANKE!

Wurde auf Win 8 Pro 64 Bit getestet und klappt. Die Funktionalität geht weit über das oben schon Beschriebene hinaus. Es handelt sich um ein spezielles Programm aus dem professionellen Druckbereich, welches zusätzlich in der Lage ist, auch alte Layoutformate (WordPerfect, Illustrator, etc. ...) layouttreu in jedes beliebige andere Format zu konvertieren. Bisher haben wir nichts gefunden, was annähernd an diese Programm (ISYS) herankommt...

Danke Sunny für den Hinweis. Wir haben die Software bereits mit WIN 8 getestet, sie läuft hier auch ohne Kompatibilitätsmodus fehlerfrei. Parallel laufen selbstverständlich Bemühungen, für adäquaten Ersatz zu sorgen. Der Editor hat aber derart einzigartige Automatismen, die wir bisher bei keinem anderen Programm gefunden haben. Es geht hier darum, in der Druckvorstufe aus den eingesandten Manuskripten (teilw. Word und Publisher) störende Zeichen automaitisiert herauszufiltern. Leider verfügen Word und Publisher über die dumme Angewohnheit, Dokumente unnötig aufzublähen. Das hat im professionellen Druck unangenehme Nebeneffekte. Und genau diese störenden Zeichen können wir nur mit diesem Editor automatisiert entfernen. Suchen und Ersetzen kann jeder OpenSource-Editor, aber anhand der Dateiendung erkennen, welche Zeichen hier störend sind und sie per Knopfdruck alle in einem Rutsch zu leiminieren, das kann bisher kein anderes am Markt befindliche Programm - leider!

Das war unsere erste Idee. Aber eine PCI (oder PCIe) Karte könnte eine Lösung sein. Auf jeden Fall werden wir erst einmal mit dem Hersteller Konatkt aufnehmen, mal sehen, was der dazu sagt. ;) Der Entwickler der Software kann leider nicht mehr ins Boot geholt werden, er ist, wie ich in meinem Eingangspost schon schrieb, vor Jahren verstorben und seine Firma ist daher erloschen. Schon mal vielen Dank Euch allen, ich halte Euch auf dem Laufenden, andere User sollen ja auch was davon haben, das ist das Prinzip von Supportforen, gelle ;) Friesenjunge

Danke Nils, für die schnelle Antwort! Der Tipp ist echt Gold wert, auf die Idee sind wir noch gar nicht gekommen :shock: Es handelt sich um einen Rainbow-Dongle Danke Dir, wir werden das verfolgen ;) Viele Grüße Friesenjunge

Moin zusammen wir haben hier ein ziemlich exotisches Problem: Seit Mitte der 1980er Jahre setzen wir ein Programm ein, das durch einen Parallelport-Dongle geschützt ist. So lange die Softwarefirma existierte, haben wir auch regelmäßig Upgrades erworben. Inzwischen ist die Herstellerfirma erloschen, da der Programmierer verstorben ist. Die Firma wurde auch nicht verkauft und ist auch nicht in einer anderen Firma aufgegangen, sondern sie existiert einfach nicht mehr. Nun wird befürchtet, dass an neueren PCs mittel- bis langfristig keine parallele Schnittstelle mehr vorhanden sein wird. Der Versuch, den (Parallelport-)Dongle über einen USB-Parallelport Konverter zu betreiben, funktionierte leider mit keinem am Markt erhältlichen Geräten. Wir suchen nun nach einem seriösem Dienstleister, der den Dongle als USB-Dongle nachbaut. Tante Google und Onkel Bing waren bislang nicht sehr hilfreich. Wer kennt einen entsprechenden Dienstleister? Danke und viele Grüße von der Nordsee Euer Friesenjunge P.S.: Ja, ich weiß, dass derartige Dinge hier nicht gerne gesehen werden und nicht supportet werden. Dennoch wende ich mich an Euch, da ich keine andere Möglichkeit sehe. Wir sind ja im Besitz einer gültigen Lizenz der letzten Version. Da die Software in der Form jedoch einzigartig ist und von keinem mehr supportet oder vertrieben wird, seid Ihr meine letzte Hoffnung.

Das Thema hat sich erledigt. Laut Auskunft unseres Lizenzhändlers ist der Product Key in dem Installationspaket enthalten, das im VLC heruntergeladen werden kann. Startet man das Setup des SQL-Servers, erkennt dieses eine vorhandene Version und wechselt in den Wartungsmodus. Dort kann man dann über das GUI ein "Edition-Upgrade" (und Downgrade) durchführen.

Moin zusammen, folgendes Szenario: SQL Server 2008 R2 Standard als Eval installiert. Entstprechende Testumgebung aufgebaut, alles roger. Nun soll das Teil produktiv gehen. In dem untenstehenden Link (Technet) http://blogs.technet.com/b/austria/archive/2010/03/06/sql-server-2008-enterprise-eval-zu-standard-ndern.aspx steht beschrieben, dass man ohne Neuinstallation die Eval in eine Produktivversion umwandeln kann. Dazu muss man auf der Kommandozeile das SQL Serversetup wiefolgt aufrufen: Setup.exe /q /ACTION=editionupgrade /INSTANCENAME=MSSQLSERVER /PID=<PID key for new edition> Nun meine Frage: Da im Volumenlizenzmanagement (Volume Licensing Service Center) angezeigt wird, dass für den SQL-Server keine Product Keys benötigt werden, bin ich am Rätseln, welche Product ID (PID Key) ich eintragen muss. Kann mir hier jemand weiterhelfen? Besten Dank!