StefanWe

Danke. Aber habe alles erfüllt was in dem Dokument steht. Das einzige was nicht ist. Ich habe Version 4.1.6.16 installiert und nicht Version 5. Allerdings gibt es ein Update für 4.1.6.17. Sollte ich dieses vielleicht mal ausprobieren. Habe gerade die Release Notes gelesen. Und genau der Fehler taucht auch auf: Aber als Known Issues. Und ur für den Web Access. Aber in weiteren Releases, taucht der Fehler nie als Fixed auf. Werde mal eine Mail an den Blackberry Support schicken.

Hallo, habe einen Blackberry und dieser wird automatisch mit Exchange 2007 synchronisiert. Was soweit auch einwandfrei funktioniert. ich trage Termine in meinem Outlook ein und ruckzuck sind sie auch auf dem Blackberry. Wenn ich aber nun einen Termin im Blackberry eintrage, wird dieser nicht an Outlook übertragen. Dieses Problem haben wir zudem bei einigen unserer Kunden. Habe schon einiges gesucht bei google, doch bis jetzt hat nichts wirklich funktioniert. Kennt jemand das Problem und hat eine Lösung oder einen Ansatzpunkt? Im Log steht folgendes Scheinbar hat der RIM Server Probleme die Mailbox des Benutzers zu öffnen. Der besadmin, welcher der Benutzer ist, der auf den Exchange zugrieft, hat für die Mailbox FullAccess. Naja vielleicht kennt ja jemand das Problem.

Du kannst die gesendete Mail nicht öffnen, weil diese mit einem Asynchronen Verschlüssellungverfahren verschlüsselt werden. Du verschlüsselst mit dem öffentlichen Schlüssel des Empfängers. D.h. es kann NUR mit dem privaten dazu passenden Schlüssel entschlüsselt werden. Da du diesen nicht hast, kannst du die Mail auch nicht entschlüsseln.

Guten Morgen, habe mich gestern bereits an Verisign gewandt. Mal schauen wann ich dort eine entsprechende Rückantwort erhalte. @OLC: Stimmt jetzt wo du es sagst, kommt mir Issuing CA aus den MS Schulungen bekannt vor ;) Also eine Issuing CA müssen wir nicht unbedingt selbst betreiben. Es würde uns schon ausreichen, irgendwo entsprechend Zertifikate zu beziehen zu können. Und dies ziemlich einfach im Sinne von wenig Verwaltungsaufwand.

Hi, also die Kunden werden keine eigene CA bekommen. Sorry falls ich mich da falsch ausgedrückt habe. @OLC was meinst du mit Issuing CAs? Es ist eben auch wichtig, das wenn der Kunde unseres Kunden Mails an seine Kunden schickt, diese ebenfalls öffentlich Vertrauenswürdig sind. Daher müssen wir irgendwoher leicht Öffentlich vertrauenswürdige Zertifikate bekommen. Und das nicht für 10.000 Euro im Jahr ;)

Überschaubar wäre das ganze schon. Ca 100 Firmen. Allerdings werden diese nicht von uns betreut. Sondern wir würden denen nur die Zertifikate für die Benutzer zur Verfügung stellen. Denn die wenigsten IT Dienstleister haben sich überhaupt schoneinmal mit dem Thema PKI befasst. Unser Zertifikat überall zu importieren wäre nicht so schön. Wobei die Datev das ja glaube genauso handhabt.

Hallo, folgende Anforderungen müssen erfüllt werden. - Öffentlich Zertifizierte CA - Ausstellen von Zertifikaten für sichere Email - Class 1 und 2 Zertifikate - Einfaches Ausstellen der Zertifikate - Für X Kunden Hintergrund. Wir haben einen Kunden, welcher nun signierte EMails verschicken möchte. Nun möchte dieser seinen Kunden wiederum auch Zertifikate zur Verfügung stellen. Wünschenwert wäre es, wenn wir eine CA Zur Verfügung haben, entweder eine eigene, oder eine von Verisign, TrustCenter, oder ähnliches., wir das Zertifikat für den Kunden beantragen. Dieses auf eine SmartCard speichern und dem Kunden zustellen. Ähnlich wie es die Datev macht. Nun haben wir uns bei Trustcenter informiert, für eine eigene zertifizierte CA wollen die 10.000 Euro pro Jahr haben. Dies rechnet sich aber nicht. Bei Verisign ist das beantragen der Zertifikate zu umständlich. Immer über die Onlineseite, dann wird das Zertifikat in den lokalen Store automatisch importiert, dort exportieren usw. - Viel zu umständlich. Hat jemand eine Idee, wie wir dies am besten Lösen können? (Es darf ruhig Geld kosten ;) )

Ok Lösung selbst gefunden. In den RDP Einstellungen muss man die Security Einstellungen von negotation auf RDP Security setzen. Dann wird keine Zertifikatsprüfung vorgenommen.

Hallo, habe hier einen Windows Terminal Server 2008. Auf diesen verbinden sich die User. Allerdings dauert der Verbindungsaufbau relativ lange. Wenn ich nun das Serverzertifikat vom WTS exportiere und beim Client importiere, geht alles ruckzuck. Nun sollen die User aber aus einer Zweigstelle sich mittels Citrix Access Gateway verbinden und der TS ist mit seinem Hostnamen extern nicht erreichbar. Zudem möchte ich das Zertifikat nicht auf alle Clients manuel importieren. (Ausrollen funktioniert ebenfalls nicht, weil keine Domäne vorhanden) Kann ich in der Terminalserverkonfiguration irgendwo ausschalten, das die Verbindung über das Zertifikat läuft? Ich konnte leider nichts entsprechendes finden.

Schau mal hier. Habe leider gerade keinen entsprechenden Microsoft Artikel gefunden. SBS2008 ? WB Wiki Wahrscheinlich kannst du die Vertrauensstellungen anlegen, aber sie werden nicht genutzt. Genauso kannst du einen zweiten SBS in eine Domäne integrieren, allerdings nach ich glaube 96 Stunden wird dieser dann automatisch heruntergefahren.

ein SBS kann keien Vertrauensstellungen

Normalerweise hat die Hardware ja einen Hardware Wartungsvertrag von dem Hersteller. Dieser läuft meist 1-3 Jahre. Nach dem dritten Jahr wird es deutlich teurer, dann muss ma nschon überlegen, ob man verlängert oder nicht in neue Hardware investiert. Kommt auch drauf an, wie wichtig der Server für den Betrieb der Firma ist. Ein WSUS Server kann ja auch ruhig 5 Jahre laufen. Zudem komt es auch auf die benötigte Performance an. Wenn diese nicht mehr ausreicht, sollte über neue Hardware nachgedacht werden.

Verwaltung->TerminalServicesConfiguration dort das RDP Protokoll anklicken und auf Properties gehen. Dort steht unten welches Zertifikat er auswählt. Entweder du erstellst dir hier ein eigenes, was Standardmäßig so gemacht wird, oder du nimmst eins von einer CA. Wenn du das selbsterstellte auf die Clients haben möchtest, geh in den Certificate Store deines machine accounts und dort findest du einen Ordner RemoteDesktop. Dort ist das server Certifikate deines RDP Servers. Dieses exportierst du. Bitte OHNE den privaten Schlüssel. Und anschließend importierst du dieses auf deine Clients.

installiere auf den Clients das entpsrechende Serverzertifikat. Dann vertraut der Client auch dem Server und alles ist gut ;) Das Zertifikat findest du in den RemoteServices Konfiguration.

@Luke1: Baue dir mal eine Testumgebung mit Windows Server und XenApp 5 bzw. nun XenApp 6 auf. Versuche hier Photoshop zu publishen mittels Citrix XenApp Online Plugin. Du könntest auch das ApplicationStreaming von XenApp nutzen um Photoshop schneller auszuführen. Welche Bandbreite haben die Clients zum TS Server?

Ich habe jetzt nochmal die Registry durchforstet und noch einige Verweise auf die den alten Pfad gefunden und diese entsprechend geändert. Im "staging" Ordner liegen zahlreiche NTFRS_* Dateien, allerdings vom 01.02.2008. Dies ist das Datum, wo das ganze gecrasht ist. Sollten diese Dateien nach einer erfolgreichen Replikation verschwinden? Ich werde heut abend einmal den Server komplett neustarten. Vielleicht hat sich das ganze Problem dann ja schon behoben. Ansonsten mit dem Raus und wieder reinstufen. Ich habe eben Angst, das das AD doch nicht so sauber funktioniert und nacher alles gecrasht ist.

Also die Freigabe wird leider nicht manuell neu erstellt. Ich habe damals in der Registry einiges an Pfaden angepasst. ich vermute das hier noch irgendwo Pfade zum "alten SYSVOL" Verzeichniss liegen. Konnte aber nichts finden. Habe aufgrund der damaligen BerechtigungsProbleme das SYSVOL Verzeichniss von d: zu c: verschoben.

Guten Morgen, vor 2 Jahren habe ich bei einem Kunden einen DC ausgetauscht, Rollen übertragen, DNS übertragen usw usw. Alles ohne Probleme. Am zweiten Tag der Migration, als ich den DC neugestartet habe, kam das AD nicht mehr hoch. Fehler waren Berechtigungen auf dem Filesystem. Habe dann mittels Abgesichertem Modus und Registry Keys das AD soweit wieder hergestellt. Bis heute funktioniert das Anmelden am Domänencontroller einwandfrei. Die Ordnerfreigaben laufen usw. Es gibt zudem einen 2. DC. Auch hier funktionieren die Anmeldungen. Im DNS stehen auch beide DCs als Anmeldeserver drin. AD soweit in Ordnung. Nun ist mir folgendes aufgefallen, wenn ich ein Anmeldescript ins SYSVOL kopiere oder eine neue Gruppenrichtlinie erstelle, werden diese Objekte auf den jeweils anderen DC nicht repliziert. Kopiere ich die Objekte manuell, geht es einwandfrei. Interessanterweise taucht auch keine Fehlermeldung im Eventlog auf. Ich möchte ungern den Haupt DC aus der Domäne nehmen und wieder hochstufen. Bin mir bei der Konstellation nicht wirklich sicher, ob das alles so funktioniert. Habe leider keine Papers zu dem Thema gefunden. Habt ihr vielleicht ein paar Stichpunkte, wie ich die SYSVOL Replikation wieder zum fliegen bekomme ?

Wichtig ist, das du die Besitzberechtigungen auf die Unterordner vererbst ( kleiner Haken unten auf dem "Fenster" )

Also das Größte Problem wird wohl erstmal der Speicher sein. 16GB RAM ist knapp bemessen. Hast du mal ein paar Sitzungen Testweise auf RDS umgestellt und geschaut, wieviel Speicher eine Sitzung im Schnitt belegt ? Dann das zweite, willst du wirklich 50 User auf einen TS bringen? Was ist wenn dieser eine Ausfällt? Ist das ein Problem, das 50 Leute nicht mehr arbeiten können ?

Neue Updates und Servicepacks von Office installiert ? Office mal repariert ?

also den cisco packet tracer kann man nicht erweitern? bzw. eine "größere" version bekommen ?

Hi, ich habe die Software Cisco Packet Tracer 5.2. Allerdings habe ich hier nur Switch bis zum 3560. oder Router bis zum 2811. Gibt es die Packet Tracer Software auch für die großen Cisco Switches wie 45/65xx ? Bzw. für die ASA oder PIX Firewalls ?

ähm, wie sieht es mit servergespeicherten profilen, bzw. terminalserverprofilen aus?

immernoch besser als die Kabel aus der Wand zu reißen und zu schauen wo sie hinführen. Natürlich kann man auch anhand der MAC am Switch feststellen, welches Endgerät dort angeschlossen ist, aber dies ist genauso mühselig. Und zu wissen, welche Dose zu zu welchem Patchpanelport führt, ist schon nicht verkehrt.