MurdocX

Diese Aussage ist so nicht korrekt! :nene: Natürlich funktioniert das auch mit Server 2012 R2 ;) Konfigurieren kannst du dies unter: Server-Manager\Remotedesktop-dienste\Sammlungen>DeineSammlung> ProgrammDeinerWahl (Eigenschaften bearbeiten) > Dateitypenzuordnung Dort den Haken setzen und die Anweisung bekommen auch deine Clients. Zur Not noch über manuelles aktualisieren am Client pushen.

Probiere es mal mit dem folgenden Powershell-Command Get-ChildItem HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\PnpLockdownFiles | Measure-Object | Select-Object -ExpandProperty Count Es gibt auch die Möglichkeit die Einträge mit der PowerShell zu entfernen, jedoch möchte ich hierfür kein Skript schreiben, ohne das Wissen, dass das unbedenklich für Dich und Nachahmer ist.

Hier noch die ausführliche Information von der Gruppenrichtlinie zum nachlesen: "Unter Windows 8 und höher können Sie festlegen, dass Updates nicht nach einem bestimmten Zeitplan, sondern während der automatischen Wartung installiert werden. Die automatische Wartung installiert Updates, wenn der Computer nicht verwendet wird; befindet sich der Computer im Akkubetrieb, werden keine Updates installiert. Wenn Updates zwei Tage lang nicht von der automatischen Wartung installiert werden können, werden Updates von Windows Update sofort installiert. Benutzer werden über einen bevorstehenden Neustart benachrichtigt, und der Neustart wird nur durchgeführt, wenn keine Gefahr für zufällige Datenverluste besteht. Die automatische Wartung kann mit diesen Gruppenrichtlinien weiter konfiguriert werden: Computerkonfiguration->Administrative Vorlagen->Windows-Komponenten->Wartungszeitplan"

Es gäbe noch die Möglichkeit die Updates während der automatischen Wartung zu installieren. Zu finden unter "Automatische Updates konfigurieren". Dann würden die Updates zwischendurch installiert und der Benutzer in den nächsten Tagen zu einem Neustart gezwungen.

Kein Problem. Siehe Gruppenrichtlinie unter "Computerkonfiguration > Administrative Vorlagen > Windows-Komponenten > Windows Update" wirst du fündig ;)

Ich vermute, dass 1und1 seine Infrastruktur schützt und somit nur Mails über Ihre eigenen Mailserver zulässt. Gibts einen authenticated smtp-connector?

Der Befehl > "Import-Module PinnedApplications" wird so nicht funktionierten, da die Powershell in einem Modulordner deines Rechners nachsieht. Hier muss der volle Pfad zu dem Modul angegeben werden. Beispiel: Import-Module "C:\Benutzer\$env:Username\PS_Module\PinnedApplications.psm1"

Wir haben das gleiche Problem gehabt. Eine vorkonfigurierte Firewall-Regel auf Basis von Server 2012 R2 funktioniert bei Windows 7 nicht. Wichtig ist hierbei, dass bei der Windows 7 Regel unter Programm "SYSTEM" eingetragen wird, dann funktioniert´s wieder. Kannst ja mal unter Windows 7 mit "wf.msc" eine vorkonfigurierte Regel erstellen und vergleichen.

Ein ernst gemeinter Rat. Man sollte an Dingen die man nicht komplett versteht, nichts verändern. Das hat nichts mehr mit "strukturieren" zu tun.

Das machen die wie sie lustig sind und ich würde dein Vorhaben auch als "nicht sinnvoll" bezeichnen. Viel Spaß damit ;-) http://www.miru.ch/how-to-control-and-prioritize-client-authentication-and-logon-requests-on-domain-controllers/ https://support.microsoft.com/en-us/kb/314861

Davon war auch NIE die Rede, sondern vom richtigen Konfigurieren... :rolleyes:

Bitte mal das Ergebnis von: ipconfig /all | clip posten. Die Daten sind damit in der Zwischenablage.

Klar! Dazu muss nur der Inhalt der Variable bearbeitet werden. Probiere es mal mit "Substring". https://technet.microsoft.com/en-us/library/ee692804.aspx http://blog.stefanrehwald.de/2013/03/03/powershell-03-2-strings-bearbeiten-und-untersuchen-mit-funktionen-wie-trim-substring-contains-tolower-toupper-startswith-endswith/

So lange das nicht zur Regel wird ;)

Hier wäre ein Powershell-Skript von mir geschrieben zur freien Wahl um Dateien umzubenennen: http://www.it-explorations.de/suchen-umbenennen-von-dateinamen-mit-powershell/

Probiere es mal damit ;) $LastLoggendOnUser = Get-ItemPropertyValue -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI -name LastLoggedOnUser

Das ist schon eine miese Unterstellung für ihn. Da muss ich jetzt mal Partei ergreifen. Gibt´s dafür Belege?

function New-FSWEvent { param ( # Enter the root path you want to monitor. [Parameter(Mandatory,ValueFromPipelineByPropertyName)] [String] $Folder, # You can enter a wildcard filter here. [Parameter(ValueFromPipelineByPropertyName)] [String] $Filter = '*.*', [Parameter(ValueFromPipelineByPropertyName)] [Switch] $IncludeSubdirectories = $false ) # In the following line, you can change 'IncludeSubdirectories to $true if required. $fsw = New-Object IO.FileSystemWatcher $folder, $filter -Property @{IncludeSubdirectories = $IncludeSubdirectories;NotifyFilter = [IO.NotifyFilters]'FileName, LastWrite'} # Here, all three events are registerd. You need only subscribe to events that you need: Register-ObjectEvent $fsw Created -SourceIdentifier FileCreated -Action { $name = $Event.SourceEventArgs.Name $changeType = $Event.SourceEventArgs.ChangeType $timeStamp = $Event.TimeGenerated Write-Host "The file '$name' was $changeType at $timeStamp" -fore green Out-File -FilePath C:\Users\Testuser\Desktop\Outlog.txt -Append -InputObject "The file '$name' was $changeType at $timeStamp" } Register-ObjectEvent $fsw Deleted -SourceIdentifier FileDeleted -Action { $name = $Event.SourceEventArgs.Name $changeType = $Event.SourceEventArgs.ChangeType $timeStamp = $Event.TimeGenerated Write-Host "The file '$name' was $changeType at $timeStamp" -fore red Out-File -FilePath C:\Users\Testuser\Desktop\Outlog.txt -Append -InputObject "The file '$name' was $changeType at $timeStamp" } Register-ObjectEvent $fsw Changed -SourceIdentifier FileChanged -Action { $name = $Event.SourceEventArgs.Name $changeType = $Event.SourceEventArgs.ChangeType $timeStamp = $Event.TimeGenerated Write-Host "The file '$name' was $changeType at $timeStamp" -fore white Out-File -FilePath C:\Users\Testuser\Desktop\Outlog.txt -Append -InputObject "The file '$name' was $changeType at $timeStamp" } } Ich kann mich blub nur anschließen. Ein Skript dauert auch für geübte durchaus etwas länger bis es fehlerfrei funktioniert ;-) Um dir zu helfen, habe ich deinen angegebenen Quellcode in eine Funktion gepackt, die du so oft wie gewünscht aufrufen kannst. Nun brauchst du nur noch eine Schleife die die richtigen Funktionsaufrufe übernimmt. EDIT: Ich habe dieses Skript nicht getestet, sondern nur deinen Quellcode verpackt.

Wir hatten ein ähnliches Problem das auf NI und diesen Dienst zurückzuführen war. 15 Min. lief "Bitte Warten..." bis die Anmeldung am Rechner möglich war. Dieser Fehler trat bei Win7 Prof. nach Updates auf, die etwas am Netzwerkstack geändert hatten. Das war sehr frustrierend für uns und die Anwender, bei 130 PCs ;-)

Offtopic: Meinen Respekt an alle die hier mithelfen! Und viel Erfolg ;)

Das stimmt, laut Microsoft und meiner Erfahrung, so nicht. ;) Ich habe diesbezüglich den entsprechenden Text wieder Fett markiert. Der Client holt sich sehr wohl vor dem Ablauf der Lease eine Neue. Das ist auch ganz gut im Log unter "C:\Windows\System32\dhcp\DhcpSrvLog-TAG.log" zu erkennen.

Der Link unterstützt hierbei die Aussage von Zahni. Und den Ausschnitt habe ich doch hier sogar noch fett markiert und das ist die Antwort auf deine Frage.

Und hier der Link dazu: https://technet.microsoft.com/en-us/library/cc958956.aspx "The length of time, specified by the DHCP server, a client computer can use a dynamically assigned IP address. When a lease is made to a client, the lease is considered active. Before the lease expires, the client renews its lease with the DHCP server. A lease becomes inactive when it either expires or is deleted by the server. The lease duration determines when the lease expires and how often the client needs to renew its lease with the DHCP server."

Klicke mit der Rechten Maustaste auf die angepinnte Anwendung, dann nochmal auf die Anwendung mit der rechten Maustaste und dort dann auf "Eigenschaften". Nun bist du in der Verknüpfung und kannst diese direkt bearbeiten. Bei mir liegen die Verknüpfungen unter: "C:\Users\%USERNAME%\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar"

Falls du die Daten aus Excel raus exportierst, dann solltest du dir auch über die Encodings im klaren sein. Hier werden die Daten mit der "ANSI"-Codierung abgespeichert. Somit musst du, um einen sauberen Import durchzuführen ein "-Encoding Default" anhängen. $ADUser = Import-Csv -Delimiter ";" -Path "c:\test\mappe1.csv" -Encoding Default Ohne Angabe, also "per default" ließt das CMDLet im "ASCII"-Encoding ein. https://msdn.microsoft.com/powershell/reference/5.1/microsoft.powershell.utility/Import-Csv @BOfH_666 Das ist mir als "logischer Fehler" erst gar nicht aufgefallen. Natürlich ist das logisch nur Benutzer anzulegen die noch nicht existieren.