Friesenjunge

Moin zusammen, haben seit vorgestern folgendes Problem: Jede E-Mail, die absenderseitig in iso-8859-1 codiert ist, werden nicht mehr korrekt dargestellt. Deutsche Umlaute werden unidentifizierbar, scheinbar wahllos, durch andere Zeichen (auch japanische) ersetzt oder fehlen ganz. Wird die Nachricht absenderseitig in UTF-8 codiert, wird sie beim Empfänger richtig angezeigt. Interessant ist, dass das Problem nur bei Nachrichten auftritt, die von externen Absendern stammen, intern verschickte Mails werden immer korrekt dargestellt, egal, was ich in Outlook als Codierung einstelle. Strange! Umgebung: Arbeitsstationen Outlook 2003, 2007, 2010. Bei allen tritt der Effekt auf Server: Exchange 2003, Patchlevel aktuell. Wer kennt dieses Phänomen und weiß evtl. wie es behoben werden kann? Besten Dank im Voraus! Viele Grüße Friesenjunge NACHTRAG Problem ist gelöst! Ursache: Barracuda Spam & Virus-Firewall. Hier war in den Optionen die Einstellung aktiviert, dass die geprüften Nachrichten bei der Auslieferung an das nachfolgende Mailsystem Barracuda-spezifische Headerzeilen mit überträgt. Nach Abschalten dieser Option wurden dfie Nachrichten korrekt dargestellt. Trotzdem Danke, Leute, und das meine ich ernst ;-) Es kann ja nicht immer jeder alle Dinge schon mal gesehen oder gelöst haben, gell? Viele Grüße Friesenjunge

Das Notebook ist ca. zwei Jahre alt und im abgesicherten Modus haben wir es noch nicht probiert.

Moin zusammen, habe an einem Windows 7 Notebook ein seltsames Phänomen: unreproduzierbar, aber relativ häufig bleibt die Uhr stehen. Bei einem Neustart stellt sich die Uhr, sie lässt sich auch manuell stellen, wenn sie wieder stehengeblieben ist. Das Eventlog zeigt keine Einträge, die auf dieses Problem hindeuten. Hatte jemand so etwas schon mal und wie könnte ich das Problem einkreisen/beheben? Danke und viele Grüße Euer Friesenjunge

@marka: Das war's! Es war nicht der aktuelle RDP Client installiert. Jetzt habe ich auch unter XP den "blauen Lappen" oben statt des gelben. Danke!

Moin zusammen, folgendes Problem: Ein Benutzer soll auf einem Terminalserver in einem entfernten Standort arbeiten. In der lokalen RDP-Datei ist angehakt, dass die lokalen Drucker als Ressource verbunden werden sollen. Leider geschieht dies nicht. Das Clientbetriebssystem ist Windows XP Professional mit aktuellem Patchlevel, der Terminalserver ist ein Windows Server 2008 R2 Standard, da ich hier aber keinen administrativen Zugang habe, ist mir das Patchlevel des Servers unbekannt. Ein anderer User setzt am Arbeitsplatz Windows 7 Professional ein, hier funktioniert es. Wo kann ich ansetzen? Vielen Dank für Eure Hilfe!

Danke Nils, für Dein ehrliches Statement. Die Frage war ja letztendlich nur, ob ich grundsätzlich daneben liege, oder ob der Ansatz zumindest in die richtige Richtung geht. Wir hatten in der Firma auch schon besprochen, das über eine gemeinsame Domäne umzusetzen, was aber auf Gegenwehr seitens des Standortes 2 stieß, eben weil sie Angst haben, dann nicht mehr Herr über ihre eigene Struktur zu sein. Alles Reden und Beschwichtigen meinerseits (Auch mit dem Hinweis, das über eine OU mit deligierter Verwaltung zu realisieren), hat hier leider nicht weitergeführt... Ich denke schon, dass Enterprise beim Exchange schon Sinn ergibt, wir haben einen und sind sehr glücklich, bei Platzmangel oder Wechsel von Mitarbeitern von einem Team ins andere das über die verhältnismäßig kleinen Datenbanken und Speichergruppen flexibel und schnell nachbilden zu können.

Autark soll bedeuten, dass jeder Standort selbst seine eigenen Benutzerkonten, Postfächer und GPOs weiterhin eigenständig verwalten soll. Es sind zwei eigenständige Firmen von einem Mutterkonzern geschluckt worden und aus Konkurrenten wurden nun Schwestern. Da herrschen einfach Bedenken in den Köpfen, und diese sollen durch die Anforderung "Autark" besänftigt werden Mit dem Standard ist die Anzahl der einzelnen Datenbanken beschränkt. Wir haben die Postfächer teamweise auf einzelne Speichergruppen und Datenbanken verteilt, um einerseits flexibler zu sein, andererseits, um bei Festplattenspeicherknappheit diese schneller und einfacher verschieben zu können, ohne gleich den halben Betrieb lahmzulegen... Ist uns bekannt, hier erarbeitet der betroffene Standort ein entsprechendes Konzept selbst.

Folgende Aufgabenstellung soll ich mal durchdenken. Da ich im Bereich AD 2008 nicht ganz so bewandert bin (MCSE 2000), möchte ich mal in die Runde Fragen, ob mein Ansatz möglich ist. Standort 1 IST-Zustand: Active Directory unter 2003 im mixed-Mode Exchange 2003 Enterprise AD Schemaänderungen durch Exchange, NAV Dynamics und SQL sind erfolgt Client-OS: WXPP & W7P Office: 2003 - 2010 User/Arbeitsplätze: ca. 200 Standort 2 IST-Zustand: Active Directory unter 2003 im mixed-Mode Mailsystem Lotus Notes Client-OS: WXPP & W7P Office: 2003 - 2010 User/Arbeitsplätze: ca. 150 Anforderungen Beide Standorte sollen autark bleiben. Lotus Notes soll durch Exchange abgelöst werden, die Frei-/Gebucht-Infos sollen standortübergreifend verfügbar sein Mails von Standort 1 zu Standort 2 sollen nicht über das Internet, sondern über die VPN-Strecke (100 MBit/s) geroutet werden. Gemeinsamer Namensraum für E-Mail-Adressen Gemeinsames, globales Adressbuch und gemeinsame Ressourcenverwaltung soll möglich sein Mein Ansatz Die in Standort 1 bestehende AD soll die Basis für eine gemeinsame Gesamtstruktur bilden, wegen vorhandenem NAV Dnamics, SQL und Exchange Standort 1 wird im AD upgegradet auf WIN SRV 2008 R2 Die dortige AD wird in den native-Mode versetzt Installation eines Exch Ent. 2010 Migration der Postfachspeicher Step-by-Step auf den Exchange 2010 Abschalten des alten Exch Erstellen einer zweiten, gleichberechtigten Domäne innerhalb der Gesamtstruktur für Standort 2 im native-Mode Standort 2 Installation eines Exchange 2010 Enterprise Migration der Lotus-User Step-by-Step auf den Exchange Ist der Ansatz zumindest als gedankliche Grundlage brauchbar, oder bin ich auf dem Holzweg? Mir war so, dass im Native AD unter 2008 eine übergeordnete "Mutterdomäne" nicht mehr erforderlich ist, sondern dass innerhalb einer Gesamtstruktur mit selbem Schema mehrere AD-Domänen gleichberechtigt nebeneinander betrieben werden können. Stimmt das so? Bin für jede konstruktive Anregung (und Korrektur!) dankbar! Euer Friesenjunge

Weil wir etliche selbstgeschriebene Makros für Word im Einsatz haben, deren Konfiguration ich mir ersparen wollte. Klare Aussage von Dir, Danke! Dann werde ich, um sauber zu bleiben, das Office an dem Arbeitsplatz komplett entfernen und neu installieren. Das zum Thema "Faulheit zahlt sich nicht aus..." ;-)

Folgendes: Wir haben im OpenValue Subscription Microsoft Office Professional Plus lizensiert. Vorher hatten wir Officelizenzen (2003) als Systembuilder. Nun war ich an einem Arbeitsplatz und habe ein vorhandenes Office 2003 Small Business auf Office 2010 ProPlus upgraden wollen. Die Installation lief glatt durch, was mich jedoch (etwas) wunderte, dass das Office nach dem Upgrade sich als 2010 Standard öffnete. Als ich dann den Volume License Key (MAK) eingeben sollte, habe ich natürlich den verwendet, der mir im eopen Volume Licensing Center angezeigt wurde, diesen hat er jedoch nicht akzeptiert. Wir haben jedoch noch in einem anderen Vertrag (Open License) mehrere Office 2010 Standard, als ich den Key von dem Standard verwendet habe, passte es. Nun meine Fragen: Ist es gar nicht möglich, ein vorhandenes Office mit dem ProPlus auf eine höherwertige Suite upzugraden? Ist das Verhalten mit dem Key so normal? Habe ich ggf. nun durch die Verwendung eines Keys aus dem "falschen" Vertrag einen Lizenzverstoß begangen? Danke für Eure Antworten! Euer Friesenjunge

Moin zusammen, wir planen, unseren in die Jahre gekommenen Druckserver auf Basis eines Windows Server 2003 zu ersetzen. Dieser ist noch eine physikalisch vorhandene Maschine. Die Neue Maschine läuft virtualisiert unter Windows Server 2008 R2 (Enterprise). Wir hasben auf dem System nun testweise einen Drucker installiert. Als Anschluss haben wir einen Standard TCP/IP Port verwendet. Treiber ist der Originaltreiber (TA/KyoceraMita KX), jedoch unsigniert. Der Drucker ist freigegeben. Hier sind aber nur die 64 Bit-Treiber vorhanden. Wollen wir nun auf der Registerkarte "Freigabe" zusätzliche 32 Bit-Treiber bereitstellen, verlangt der Server nach dem Verzeichnis "i386" von der Windows-CD/DVD. Nun die Frage: Will der Server hier nun das i386 eines Clientbetriebssystems haben? Danke!

@Norbert: Schade, oder gut (?!), dass ich kein Entwickler bin... ;)

Tja, schade, aber nicht zu ändern... Off-Topic: Obwohl, doch: In dem man selbst was entsprechendes Programmiert...

Stimme Dir voll zu, Norbert. Wenn ich mir jedoch die Preise eines Standalone-Outlook 2010 anschaue, käme OWA bei dem Kunden schon in Frage... Gäbe es denn nennenswerte Alternativen zu Outlook? Ggf. Open Source?

OK, Danke schon mal. Als Alternative käme in dem Fall ja dann zunächst OWA zum tragen.

Moin zusammen, habe hier eine Frage von einem Kunden bekommen. Da ich lizenztechnisch nicht der fitteste bin, frage ich vorsichtshalber erst mal hier, bevor ich "aus dem Bauch heraus" meinem Kunden etwas falsches erzähle. Folgende Situation: Kunde setzt bisher einen Kommunikationsserver auf Basis von Linux ein. Dieser soll aufgrund des Alters und fehlender Funktionen durch einen Exchangeserver ersetzt werden. Neue Hardware würde dafür angeschafft werden. Clientumgebung: ca. 150 Arbeitsstationen mit Windows XP Pro und Windows 7 Pro. (Jeweils OEM) Eingesetztes Office: Bisher OpenOffice/LibreOffice, laut dem Kunden völlig ausreichend. Eine Migration auf MS Office soll vermieden werden (wg. gefürchteten Inkompatibilitäten vorhandener OpenOffice Makros in MS Office und den Anschaffungskosten). Frage: Bringt ein ordnungsgemäß lizensierter Exchange (Serverlizenz, Exchangeserver Lizenz und entsprechende Server CALs und Exchange CALs) gleichzeitig eine Outlooklizenz mit, um auf den Clients die volle Exchange-Funktionalität nutzen zu können oder ist der Kunde gezwungen, dann ein OfficePaket von Microsoft zu kaufen/lizensieren? Als (Zähl-)Grundlage sähe ich da die Exchange CALs, also z.B. 150 EXCH CALs = 150 x Outlook, jeweils in der zur Exchangeversion passenden Edition. DANKE für Eure Hilfe! Euer Friesenjunge

Das betroffene System weist die selben Extensions auf, wie mein rund laufendes System. Ich kann nichts verdächtiges finden...

Das Ereignisprotokoll sagt leider zu dem Punkt gar nichts. Der Rechner ist ein Core2 mit 2048 MB RAM, Performancemäßig eigentlich im grünen Bereich. Von dieser Baureihe haben wir etliche Systeme im Einsatz, jedoch zeigt nur dieser das beschriebene Verhalten. Ich habe das Gefühl, dass der Explorer in der Zeit hängt, denn wenn ich mit der Maus während der Wartezeit über die Taskleiste fahre, sehe ich nur die Sanduhr. Wir hatten mal Novell im Einsatz, aber sowohl der Novellclient selber, als auch der MS-Client für Novell wurden deinstalliert. Die NWGINA.DLL wurde auch korrekt entfernt und nun wird wieder die MSGINA.DLL verwendet, da hatten wir bei einem anderen Rechner das Problem, dass er im Hintergrund versuchte, zuerst auf den nun nicht mehr vorhandenen Novellserver zuzugreifen. Aber das können wir ausschließen. Ich möchte vermeinden, den Rechner komplett neu aufsetzen zu müssen...

Moin Forengemeinde, folgendes Problem: Wir haben hier einen Client-PC, bei dem der Zugriff auf Dateien, egal, ob lokal oder aus dem Netzwerk, sehr langsam von Statten geht. Egal, ob man eine Datei öffnet, das Kontextmenü aufruft oder löschen möchte, dauert es zwischen 30 und 120 Sekunden, bis entweder die Datei geöffnet wird, das Kontextmenü oder die Sicherheitsfrage vom Löschen erscheint. Das Verhalten ist unabhängig vom angemeldeten Benutzer, selbst beim lokalen Administrator zeigt sich das Phänomen. Virenschutz wurde testweise deaktiviert (ohne Netzwerkanbindung), keine Besserung. Mit Sysinternals FileMon mal geforscht: Nix gefunden! Mit Taskmanager/ProcExplorerzeigen sich auch keine seltsamen Prozesse Mit Fremd-OS gebootet und Virenscan gemacht (C't Desinfec't): Virenfrei! Patchlevel: Aktuell Hat jemand von Euch noch eine Idee? Besten Dank Friesenjunge

So, noch ein Nachtrag: ich habe nun mal im Eventlog nachgeschaut (hätte ich auch vorher drauf kommen können). Dort findet sich folgender Eintrag: Was mich wundert an der Sache ist der Umstand, dass ich als DNS-Server exakt die selben Server angegeben habe, wie auf den anderen Clients, an denen die Richtlinie greift... Namensauflösung klappt auch, sonst hätte ich den Client ja nicht in das AD aufnehmen können. Strange!

Moin zusammen, wir haben hier für ein paar PCs in der Produktion eine GPO erstellt, um einem Benutzer bestimmte Restriktionen aufzuzwingen (Kein Explorer, kein "Ausführen", spezielles Startmenü, etc. ...). Die PCs, an denen sich dieser User anmelden darf, als auch das Userobjekt selbst befinden sich in der OU, auf der die GPO gesetzt ist. An allen PCs funktioniert es korrekt, nur bei einem PC ziehen die Richtlinien nicht. Der PC ist selbstverständlich in der Domäne und liegt auch als AD-Objekt in der korrekten OU. GPresult auf dem betroffenen Client gibt mir die Antwort [Nachtrag] Habe auf dem betroffenen PC nun folgende Schritte durchgeführt, um das Problem einzukreisen: PC aus dem AD entfernt (über sysdm.cpl auf dem Client) Computerobjekt im AD manuell gelöscht PC wieder dem AD hinzugefügt gpupdate /Force Leider hat beides nicht zur Lösung beigetragen, bei gpresult kommt nach wie vor die o.g. Rückmeldung... Wo kann ich jetzt weiter ansetzen, um das Problem zu lösen? Bin gespannt und freue mich auf Eure Antworten. Besten Dank im Voraus! Der Friesenjunge

Hallo Gemeinde! Es gab von Microsoft mal ein Tool, mit dem man die im Netzwerk installierten Microsoftprodukte ermitteln konnte. Ich habe bei MS vergeblich versucht, das Tool zu finden. Kann mir von Euch einer einen Tipp geben? Danke Friesenjunge