Indien je Powershell opstart op een Windows Server 2008 krijg je de volgende foutmelding te zien:
WARNING:
File C:\Windows\system32\WindowsPowerShell\v1.0\Modules\PSDiagnostics\PSDiagnostics.psm1
cannot be loaded because the execution of scripts is disabled on this system.
Please see “get-help about_signing” for more details.
Het probleem is op te lossen door de volgende code in Powershell uit te voeren:
Set-ExecutionPolicy Unrestricted
maandag 3 oktober 2011
Group Policy Modeling
Hieronder een link naar een interessant artikel over Group Policies.
http://blogs.technet.com/grouppolicy/archive/2009/08/06/cool-articles-group-policy-modeling-windows-7-server-2008-r2-functionality.aspx
Er staan twee links in bovenstaand artikel:
http://searchwindowsserver.techtarget.com/tip/0,289483,sid68_gci1347416,00.html
en
http://searchwindowsserver.techtarget.com/tip/0,289483,sid68_gci1363466_mem1,00.html?track=NL-468&ad=718481&asrc=EM_NLT_8862218
http://blogs.technet.com/grouppolicy/archive/2009/08/06/cool-articles-group-policy-modeling-windows-7-server-2008-r2-functionality.aspx
Er staan twee links in bovenstaand artikel:
http://searchwindowsserver.techtarget.com/tip/0,289483,sid68_gci1347416,00.html
en
http://searchwindowsserver.techtarget.com/tip/0,289483,sid68_gci1363466_mem1,00.html?track=NL-468&ad=718481&asrc=EM_NLT_8862218
Hide users from Windows 2008 Server logonscreen
Stel je hebt een Windows 2008 server draaien en je wilt daar iemand rechten op geven, maar je wilt niet dat die namen op het loginscherm te zien zijn. Je moet dan in het register deze namen toevoegen.
Ga naar:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList
Als de key UserList nog niet bestaat maak deze dan aan.
In deze key voeg je een DWORD toe met de naam van de gebruiker en geef deze de value 0.
Ga naar:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList
Als de key UserList nog niet bestaat maak deze dan aan.
In deze key voeg je een DWORD toe met de naam van de gebruiker en geef deze de value 0.
Group Policy Central Store
Ik vind het vreemd waarom MS standaard geen gebruik maakt van de Central Store. Mijn advies is daarom ook om standaard ook bij een single-DC omgeving een Central Store aan te maken.
Het aanmaken van de Central Store is eenvoudig. Je moet na het uitvoeren van dcpromo (die ervoor zorgt dat NTDS.dit en de SYSVOL dir aangemaakt wordt) de mapinhoud verplaatsen.
van
“C:\Windows\PolicyDefinitions”
naar
“%SystemRoot%\SYSVOL\domain\Policies\PolicyDefinitions”
Deze laatste map moet je even handmatig aanmaken anders staan de rechten niet goed.
DFS zorgt er nu voor dat alle DC’s deze templates gebruiken.
Het aanmaken van de Central Store is eenvoudig. Je moet na het uitvoeren van dcpromo (die ervoor zorgt dat NTDS.dit en de SYSVOL dir aangemaakt wordt) de mapinhoud verplaatsen.
van
“C:\Windows\PolicyDefinitions”
naar
“%SystemRoot%\SYSVOL\domain\Policies\PolicyDefinitions”
Deze laatste map moet je even handmatig aanmaken anders staan de rechten niet goed.
DFS zorgt er nu voor dat alle DC’s deze templates gebruiken.
Schemamaster
Om de schemamaster snap-in te kunnen gebruiken dient deze eerst geregistreerd te worden.
In CMD met Elevated Rights: regsvr32 schmmgmt.dll
A schema master is one of the five operations master roles in Active Directory. It manages and controls the definition of each object and its associated attributes in the directory. It functions in the forest level in a single master fashion and exists once in a forest. Only one domain controller in a forest is allowed to perform the schema master role. By default, the first domain controller installed in an enterprise acts as the initial schema master.
In CMD met Elevated Rights: regsvr32 schmmgmt.dll
A schema master is one of the five operations master roles in Active Directory. It manages and controls the definition of each object and its associated attributes in the directory. It functions in the forest level in a single master fashion and exists once in a forest. Only one domain controller in a forest is allowed to perform the schema master role. By default, the first domain controller installed in an enterprise acts as the initial schema master.
Werkstations extra beveiligen
Op werkstation draait een service (Group Policy Cient) die ervoor zorgt dat de GPO worden gedownload en door de juiste Client Side Extension (CSEs) worden uitgevoerd.
Indien door een of andere rede lokaal een instelling wordt gewijzigd die eerder door een GPO was ingesteld zal deze gewijzigde instelling blijven staan totdat de desbetreffende GPO wordt aangepast. Standaard voert een CSE alleen acties uit als een GPO gewijzigd is.
Om ervoor te zorgen dat een CSE de GPO instellingen toch uitvoerd ookal is er niets aan gewijzigd kun je een GPO instellen:
“Computer Configuration\Policies\Administrative Templates\System\Group Policy”
Hierin staan de corresponderende CSE configuratie en kun je instellen dat een bepaalde CSE altijd een GPO moet inlezen/uitvoeren.
Indien door een of andere rede lokaal een instelling wordt gewijzigd die eerder door een GPO was ingesteld zal deze gewijzigde instelling blijven staan totdat de desbetreffende GPO wordt aangepast. Standaard voert een CSE alleen acties uit als een GPO gewijzigd is.
Om ervoor te zorgen dat een CSE de GPO instellingen toch uitvoerd ookal is er niets aan gewijzigd kun je een GPO instellen:
“Computer Configuration\Policies\Administrative Templates\System\Group Policy”
Hierin staan de corresponderende CSE configuratie en kun je instellen dat een bepaalde CSE altijd een GPO moet inlezen/uitvoeren.
Loopback processing of Group Policy, explained
Today I want to write a few words about Loopback processing of Group Policy. When you deal with this setting for the first time it may be a little bit confusing. You can find explanations of this policy setting on the internet, but in my case I will try to explain everything in simple words.
As we know group policy has two main configurations, user and computer. Accordingly, the computer policy is applied to the computer despite of the logged user and the user configuration is applied to the user despite of the computer he is logged on.
For example we have a Domain, this Domain has two different organizational units (OU) Green and Red, Green OU contains a Computer account and Red OU contains User account. The Green policy, which has settings “Computer Configuration 2” and “User Configuration 2” is applied to the OU with the computer account. The Red policy, which has settings “Computer Configuration 1” and “User Configuration 1”, is applied to the OU with the User account. If you have a look at the picture below it will become clearer.
If Loopback processing of Group Policy is not enabled and our User logs on to our Computer, the following is true:
As we can see from the picture, the User gets Computer Configuration 2 and User Configuration 1. This is absolutely standard situation, where policies are applied according to the belonging to the OU. User belongs to the Red OU, he gets the Red User configuration 1 accordingly.Now let’s enable the Loopback processing of Group Policy for the Green OU. In this case if the User logs on to the Computer, the policies applied in the following way:
As we can see, now the User is getting User Configuration 2 despite of the fact that he belongs to the Red OU. So, what has happened in this scenario, the User Configuration 1 was replaced with the User Configuration 2, i.e. with the configuration applied to the Computer account.As you have probably noticed, the picture above says “Loopback in replace mode”. I have to mention that the Loopback processing of Group Policy has two different modes, Replace and Merge. It is obvious that Replace mode replaces User Configuration with the one applied to the Computer, whereas Merge mode merges two User Configurations.
In Merge mode, if there is a conflict, for example two policies provide different values for the same configuration setting, the Computer’s policy has more privilege. For example in our scenario, in case of the conflict the User Configuration 2 would be enforced.
In the real work environment Loopback processing of Group Policy is usually used on Terminal Servers. For example you have users with enabled folder redirection settings, but you do not want these folder redirection to work when the users log on to the Terminal Server, in this case we enable Loopback processing of Group Policy in the Policy linked to the Terminal Server’s Computer account and do not enable the folder redirection settings. In this case, once the User logged on to the Terminal Server his folder redirection policy will not be applied.
As we know group policy has two main configurations, user and computer. Accordingly, the computer policy is applied to the computer despite of the logged user and the user configuration is applied to the user despite of the computer he is logged on.
For example we have a Domain, this Domain has two different organizational units (OU) Green and Red, Green OU contains a Computer account and Red OU contains User account. The Green policy, which has settings “Computer Configuration 2” and “User Configuration 2” is applied to the OU with the computer account. The Red policy, which has settings “Computer Configuration 1” and “User Configuration 1”, is applied to the OU with the User account. If you have a look at the picture below it will become clearer.
In the real work environment Loopback processing of Group Policy is usually used on Terminal Servers. For example you have users with enabled folder redirection settings, but you do not want these folder redirection to work when the users log on to the Terminal Server, in this case we enable Loopback processing of Group Policy in the Policy linked to the Terminal Server’s Computer account and do not enable the folder redirection settings. In this case, once the User logged on to the Terminal Server his folder redirection policy will not be applied.
Abonneren op:
Posts (Atom)