Sana

Ausgezeichnet funktioniert danke!

und nur mal so nebenbei. Typisch, dass dieser Punkt nur in der Kategorieansicht zu finden ist. Bei der Detailierten ist es nämlich nicht zu finden.

Hallo!

Mir wurde ein Fall unterbreitet, wo jemand die Minianwendung "Währungsrechner" deinstalliert hat (also wirklich im Minianwendungsmenü auf deinstallieren). Dummerweise war es ein Versehen und er braucht das Teil recht dringend. Nur leider ist es nirgendwo aufzufinden. Die von Microsoft angebotenen Websites haben den Standardrechner anscheinend nicht als Download zur Verfügung. Weiss jemand zufällig wo das aufzufinden ist, oder gibts da einen trick?

mfg

Sana

Hmm, unter Umständen meinst du ein Problem mit dem neuen Kommunikationsscript dass in win 7 integriert wurde und bei der Kommunikation mit 2003 Servern manchmal Probleme verursacht. Quote ausm Technet:

The problem happened because somehow the Win7 client was trying to communicate with the printer server via the Asynchronous RPC protocol. This protocol is a new protocol only supported in Windows 2008 and Windows 2008 R2 printer serves. Because your printer server is Windows 2003, it does not support this Asynchronous RPC protocol so the Win7 client failed to communicate with it.

 

There is a simple workaround for this problem, which is to add the following registry value and set its data to “6”. This will disallow the use of the Asynchronous RPC protocol on the client, so the client will always try to communicate with the normal RPC protocol and therefore the problem should not happen again.

Quelle

Füge einfach diesen regkey hinzu:

HKLM\Software\Policies\Microsoft\Windows NT\Printers\EnabledProtocols

DWORD (32bit)

Wert: 6 dezimal

Alternativ könnte aber auch dieser Hotfix helfen, liess dir jedoch genau durch was er tut ;)

Hotfix:

A computer that is running Windows 7 or Windows Server 2008 R2 intermittently cannot use a shared network printer to print

Dann ändere es einfach - rdp datei vorbereiten und per commandline mit mstsc <verbindungsdatei>starten, alternativ rein damit in den Autostart.

Über commandline gehts sonst soweit ich weiss garnicht.

meinst du diesen Fehler?

Source: MSExchangeTransport Event ID: 12015 (Exchange 8.0) - Technet Events And Errors Message Center: Message Details

Wenn ja, dann folge einfach den beschriebenen Schritten.

naja dann ist die Frage, was bekommst du für einen Fehler?

also den Unzustellbarkeitsbericht

Rechte maustaste auf die seite

Edit bindings... auswählen

https Binding anklicken und auf Edit.. gehen

Zertifikat auswählen Das sollte halt bei ex 2007 schon das benutzte Zert sein. ansonsten solltest du es über ie Powershell mit dem

enable-Newcertificate befehl für IIS aktrivieren, dann sparst dich auch das händische rumfuddeln

der Exchange muss für die mail domain verantwortlich sein, sonst geht nichts. Welche Emailadressen deine User haben, konfigurierst du dann einfach in der Richtlinie.

was sagt das eventlog?

Gibt es einen genaueren Fehler, wenn sich der Admin anmeldet?

Eventuell könnt ihr versuchen, die englische Sprache zu deinstallieren. Dann sollte es zumindest nicht mehr zurückspringen können.

Also das Einbinden der anderen DNS Zone sollte auf jedenfall gehen, vielleicht liegt da der Hund begraben. Was bekomsmt den fürn Fehler wenn versuchst, die Zone zu syncen?

Wir haben etwas ähnliches in Betrieb, zwei Domains, Netzwerke über ne MPLS verbunden. Vertrauenstellung aktiv, User sind in Grps eingebunden. Hier rennts ohne weiteres. Also gehen muss es irgendwie :)

Laufen alle Tests in der Vertrauensstellung durch?

Und versuch mal die Zonen auf den jeweils fremden DNS als sekundäre zone einzubinden und zu synchronisieren

Mag jetzt lächerlich klingen, aber hat dein User ein Password?

Sind die Dateien wirklich verschlüsselt? diese Endung ansich heisst ja noch garnichts. Und vor allem, um welchen Virus handelt es sich?

Ohne weitere Infos kann ich dir nur diesen Link anbieten:

HEUR-DBLEXT/Crypted - Vollstndig

es gibt diverse Unterarten des Virus aber der Context ist derselbe

hmm ich würd ein Abmeldescript verwenden

del /s /f /q %TEMP%\*.*

Du musst im AD auf jedenfall die Terminalservices Profilpfade eintragen und dafür Ordner mit ensprechenden Rechten im Netzwerk erstellen. Danach bekommt der User nach dem ersten login ein Standprofil reingespielt. Am besten wäre es wenn der User sich das einfach einmal einrichtet. Theoretisch ist es teilweise möglich Profile von den lokalen Maschinen in den TSprofilpfad zu kopieren und dann zu laden wenn es sich um kompatible OS handelt(XP 2003), allerdings würde ich davon abraten, da es teilweise zu seltsamen Vorkommnissen kommen kann. Z.b Standardrucker nicht einrichtbar und anderes.

so Problem gelöst, tatsächlich hing es daran, dass der IIS MAnager das Zertifikat auf der External Seite immer wieder zurückgesetzt hat wenn man den IIS neu gestartet hat.

Intern gingen die Webseiten deshalb richtig und von aussen hin sah es so aus als würde irgendwas gecached werden...

dazu sagt man wohl selfowned :>

naja nun neues Zertifikat erstellt:

New-ExchangeCertificate `
-GenerateRequest `
-SubjectName "c=AT, o=Firma, ou=IT, cn=owa.Firma.com" `
-IncludeAcceptedDomains `
-IncludeAutodiscover `
-DomainName owa.firma.com,owa `
-privatekeyexportable $true `
-Path c:\e2007.req

Import-ExchangeCertifiacte C:\e2007.cer

Enable-ExchangeCertificate -Thumbprint "irgndwas" -Services IIS,POP,IMAP,SMTP

Eingepflegt, aber die Erreichbarkeit ist immer noch nicht gegeben. Und seltsamerweise hat der Server bei der extern erreichbar ist, immer noch das alte Zertifikat drin :(

Hallo!

Ich habe derzeit ein Problem mit der Erreichbarkeit meines OWAs. Hier ist das Szenario:

2 Domänen in einer Gesamtstruktur. Beide Domänen haben eine eigene CA (da es sich fast um getrennte Firmen handelt)

Die Exchangeserver sind in einer Organisation haben aber je eine eigene Maildomäne. Auf beiden Exchangeservern ist OWA eingerichtet. Da die Zertifikate der beiden webseiten grade am Ablaufen sind, haben wir diese folgend erneuert:

Über IIS die Anforderung auf Erneuerung gestellt und am CA authorisiert, zurückkopiert und per Powershell dann authorisiert.

Nun kommt das spannende:

Bei den Domänen kommt, wenn man https://server.domain.local/owa'>https://server.domain.local/owa die webseite mit dem neuen Zertifikat daher. Soweit alles gut. Extern jedoch wird immer noch das alte Zertifikat angezeigt. Das gleiche gilt für outlook anywhere. Auch hier wird immer noch das alte Zertifikat ausgeworfen.

Testweise habe ich dann bei einer der Maildomänen das alte Zertifikat nach Sicherung gelöscht. Vorher wurden alle services auf das neue übertragen. Komischerweise ist nun webaccess überhaupt sicht verfügbar (mit oder ohne ssl) wenn man https://server.domain.local/owa benutzt.

Kurioserweise bekommt man jedoch den OWA bereitgestellt wenn man nur den lokalen Domainnamen ala

https://domain.local/owa benutzt. Ebenso funkts mit der IP

Und bevor ich nun zu drastischen Mitteln ala Deinstallieren des CAS und IIS greife wollte ich fragen ob ich etwas offensichtliches übersehen habe.

Auch würde mich interessieren warum extern und intern verschiedene Zertifikate bei gleichen Webseiten angezeigt werden.

mfg

sana

BES 4.6 unterstützt keinen Exchange 2007 sp1, das ist das Problem. Und dass es grob fahrlässig ist weiss ich auch :)

Derzeit siehts nunmal so aus, dass ich nur für diesen Server ien Wartungsfenster bekomme. Der zweite Server muss unbedingt in betrieb bleiben, und der dritte untersteht nicht meiner Administration... abgesehen davon dass er ein paar hundert Kilometer weg ist und ohne physischen Zugriff is das immer so ne sache.

Die zwei anderen Server sollten jedoch dieses Monat ebenso weiter hochgezogen werden.

Direkt auf SP 3 zu gehen wäre eine anderen Möglichkeit, ob ich das bewilligt bekomm ist jedoch ne andere Sache, mal davon abgesehen wie die Kombatibilität da aussieht.

Hallo!

Ich müsste diesen Freitag einen sp1 auf einen Exchange 2007 installieren. Dabei stellt sich mir nun folgende Frage:

ie Organisation hat derzeit 3 Domänen in einer Gesamtstruktur und in jeder dieser Domänen steht ein Exchange 2007. Alle drei Installationen sind derzeit auf demselben Stand ohne diverse SPs und Co (Eine alte Blackberry Enterprise Version ist der grund warum hier noch nie was gemacht wurde).

Nun soll auf einen der drei Exchangeserver der servicepack installiert werden. Es handelt sich dabei um den Exchange der in der Ersten Domäne am Schemamaster installiert ist. Ich habe mich schon ein bisschen informiert, was genau hier passiert und lt. MS wird das Schema bei der installation verändert. Die Frage die sich mir dabei stellt ist, ob es dadurch zu problemen bei den anderen Exchangeservern kommen kann. Ebenso befindet sich der alte BES noch im Betrieb, allerdings wurden alle Mailboxen des zu patchenden Exchanges bereits entfernt.

Mit welchen Problemen muss ich rechnen oder besser, ist es überhaupt möglich ohne die Funktionalität der anderen Dienste zu beeinträchtigen?

mfg

sana

hmm ansich benutze ich als nostalgiegründen immer noch die kombi von warnungen und blat.

in windows 2008 sind die warnings allerdings in die data collector sets übergegangen.

einfach den perfmon starten, da drinnen isses :)

Hoi,

Bei aRcserv 12 ist es nicht mehr nötig den Windows Treiber zu deaktivieren und es stellt ansich auch kein Problem mehr da, einen Treiber vom Hersteller zu benutzen.

Ansonsten würd ich das Gerät aus Arcserv mal Rauswerfen und neu reinbringen. Ausserdem solltest du in den Optionen die Bandlaufwerksprotokollierung aufdrehen wenn dus noch nicht hast. Zu finden ist die Einstellung

unter Serververwaltung -> Konfiguration - > Bandprozess

Ebene Einstellen, Protokoll im Job anzeigen usw

Reverslookup hat Funktioniert. Beide IP Addressen sind mit dem selben DNS Namen der FArm gesetzt. Nur falls jemand das geliche Problem hat :>

Hat der User das Recht, sich als Dienst anzumelden?

ich hab in der ersternen Domain nun mal reverselookups

für die Farm eingetragen. Vielleicht löst dies ja unser Problem.