zahni

Dann macht ein WSUS Sinn. Und Du hast mehr Kontrolle über die Updates. Man könnte sie z.B. vorher testen ;)

Wenn Du einen WSUS-Server verwendest, bekommst Du alle Updates.

Wenn die Daten im AD gepflegt sind, würde ich mal prüfen, ob die die anderen Anwendungen an das AD anbinden lassen. Im einfachsten Fall geht das über LDAP. U.U. kann man dann in Kombination auch ein SSO-Verfahren über NTLM oder Kerberos einführen. PS: Als Referenz: http://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-communications-manager-version-71/112880-cucm-8x-ldap.html

Schau mal hier: http://de.wikipedia.org/wiki/File_Transfer_Protocol Speziell die Unterschiede "Aktiv" und "Passiv" Bei Passiven FTP muss der Server dem Client die richtige (öffentliche) IP-Adresse übermitteln und nicht seine NAT-Adresse.

Ich verstehe immer nicht, warum Du den aktuellen Benutzernamen von der Datenbank wissen willst. Wenn Deine Web-Anwendung im Browser SSO macht (aktuell wage ich das zu bezweifeln), bekommt Deine Anwendung die Daten vom jeweiligen Webserver. Den SQL-Server kannst Du damit in Ruhe lassen. Es gibt in PHP auch irgendeine Funktion, mit der man alle Server-Variablen dumpen kann.

Manchmal stimmt die Kodierung bestimmter Sonderzeichen nicht, wenn man etwas per Copy&Paste von einer Webseite kopiert. Das sieht dann optisch korrekt aus. Es ist aber ein Unterschied, ob man ' , ` oder ´ benutzt ;)

Das sehe ich ein wenig anders. Bei BCS meldet man sich optimaler weise mit einem im Secure Store hinterlegten Konto bei einer externen Datenquelle an. Die Zugriffsrechte auf diesen BCS kann man dann im BCS konfigurieren. Bei einem Webservice mag das im Speziellen anders sein. Bei Datenbanken sollte man das aber eher vermeiden. Direkt durchgereichte Datenbank-Anmeldungen wurden schon oft zum Hacken von (DB)-Servern verwendet.

Auch wenn die Anwendung sich per Browser-SSO anmeldet, sollt diese Anmeldung nicht an den SQL-Server durchgereicht werden. Nur als Beispiel: SharePoint macht das auch nicht. So etwas kann eine erhebliche Sicherheitslücke öffnen. Speziell wenn die Anwendung auch eine alternative Anmeldemöglichkeit bietet. Sie Anwendung selbst kenne ich nicht. Normalerweise kann man aber bei Web-Anwendungen via SSO den Usernamen aus den Servervariablen extrahieren. Bei ASP (vbscript) wäre dies Request.ServerVariables("AUTH_USER")

Ich kann hier nur allgemein antworten: Bei PHP gehe ich mal von einer Web-Anwendung aus. Es ist ein ganz schlechtes Design, wenn ein User sich über ein Web-Frontend direkt auf einen Datenbankserver anmeldet. Hier sollte nach Möglichkeit immer mit technischen Usern gearbeitet werden, deren Konten nicht weiter bekannt sind. Zum Session-Sharing zwischen anderen Anwendungen gibt es genügend Lösungen. Man schreibt die (User).Daten aber nicht ein Cookie. Selbstverständlich ist das auch Abhängig von der konkreten Anwendung.

Hier kann er doch weiterhüpfen: ;)

Am Einfachsten in der windowsupdate.log

So ist es immer: Von den Kunden werden die Informationen geglaubt, die am Besten in den Kram passen. Die sind dann auch "richtig" ;)

Welche Edition willst Du denn haben? PS: Für Foundation: http://www.microsoft.com/de-de/download/details.aspx?id=42039

Für 2012 R2 benötigst Du SP2013 SP1 . Ich wüsste nicht, dass man AppFabric händig konfigurieren müsste oder sollte. Die Prerequisites lässt Du man Besten vom Installer herunterladen und installieren Für den SQL-Server solltest Du einen Alias konfigurieren. Den Native Client für SQL 2012 kannst Du ebenfalls installieren.

Wenn Du NAT dazwischen hast, brauchst Du einen Tunnel: Also VPN.

Ich diese Betriebsart ist IHMO nicht vorgesehen, da sie aus AD-Sicht keinen Sinn macht. Wenn das nicht möchtest, musst Du die Firewall, z.B. im Windows-Server entsprechend konfigurieren. Allerdings wirst Du die Funktion "anmelden" an einen DC und "User anlegen" nicht voneinander trennen können. D.H. jeweilige PC kann sich dann nur noch über den einen zentralen DC authentifizieren (wenn er ihn den findet. Das wird eher auf Fehlermeldungen hinauslaufen). Eventuell geht was über den http://technet.microsoft.com/de-de/library/cc771234(v=ws.10).aspx . Leider kenne ich mich mit dem "Monster" nicht aus Edit: Mir fällt eigentlich nur ein Grund ein, warum das zentralisieren sollte. Die Securtiy-Events auf den DC. Falls es darum geht, seit Ihr eventuell besser beraten ein passendes identity Management System einzuführen. Solche Systeme können alle Aktionen entsprechend der Anforderungen ausführen und protokollieren. Ohne dass der jeweilige User irgendwelche Rechte im AD braucht.

Jetzt nochmal von vorne: - Du hast eine Zentrale. Die hat eine "25G"-Anbindung an das Internet. Was ist das genau für eine Leitung? - Die Standorte verbinden sich per DSL. Wie genau? Gibt es ein VPN? Wenn ja, was ist das für ein VPN?

Darf ich fragen, was das bringen soll? Die Daten werden doch hinterher eh repliziert. Da ist egal, gegen welchen DC die Änderung erfolgt. Wie der User lokal das.msc starten darf spielt keine Rolle. Er braucht dazu ganz sicher keine lokalen Adminrechte. Die Änderungen in der Domäne erfolgen mit den jeweiligen Domänen-Konto. Und ja, man kann einzelnen Usern sogar auf OU's beschränkt, entsprechende Rechte erteilen ohne dass der User dann Domänen-Admin ist. Edit: Wenn es verschiedene Standorte sind, müsstest Du Dein AD in Standorte aufteilen. Wenn das richtig funktioniert, wird DSA.MSC auch den lokalen DC verwenden.

Du hast also Citrix installiert. Möchtest Du uns noch mehr erzählen? Z.B. mit welchem RDP-Client greift Du auf den Server zu, welche Citrix-Version, usw. Hier gibt es was zum Thema: http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Q_27215653.html

Was stehen oder standen denn dort für Fehler?

Mit Kixtart $dayleft=@maxpwage-@pwage If $dayleft>-1 and $dayleft<=10 messagebox("Ihr Passwort läuft in $dayleft Tag(en) ab.@CRLFDrücken Sie STRG-ALT-ENTF und wählen Sie@CRLFdie Option 'Kennwort ändern'.","Passwort-Warnung",4160,0) ENDIF Bekommt man sicher auch mit Powershell hin.

Sieh auch http://www.mcseboard.de/topic/199364-ms-zieht-sicherheitsupdates-zurück/ Wobei mich mal interessieren würde was auf den betreffenden PC's anders ist. Ich konnte den Fehler noch nicht nachvollziehen.

Die Beste Maßnahme wäre, nicht überall an der Kostenschraube zu drehen, qualifizierte Leute zu beschäftigen und die dann gut zu bezahlen. So weit kommt es aber ganz sicher nicht ;)

Hast Du das Tool mal mit einem Admin gestartet, der im gesamten Forest entsp. Berechtigungen besitzt?

Das kann ich aus der Ferne leider beurteilen. Eventuell muss die Anwendung warten, bis der Explorer oder die Netzwerk komplett gestartet ist.