How would I set the "overwrite as needed" setting on Event logs other than Application/Security/System? Specifically I'd like to apply this to the Powershell and Windows Powershell Logs, in addition to any other future logs that may be added. This needs to be applied to both server 2003 & 2008.
Wow. I looked around on this and can't find any references to set GPO settings for event logs other than for System, Application, Security. That just seems wrong. You will have to script it for your domain or workgroup or workstation with wevtutil.exe (cmd) or limit-eventlog (powershell). Both utilities have remote connection built in.
wevtutil sl <Log Name> /rt:false
limit-eventlog -Log Name -OverFlowAction OverwriteAsNeeded
I don't believe their is a GPO for this. But most group policies simply modify the registry.
You could create an adm template that modified the settings, or you could simply write a script to adjust the settings.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\PowerShell
If you are not sure how to manually configure the settings, simply adjust the settings in the event log GUI, and set all your other systems to be the same. You may need to restart the system for the changes to go into effect.
Right now you'd need to use SDM Software's GPO cmdlets. That's the only way from within PowerShell to modify the settings within a GPO. But there's no way that I know of to make a change to "any logs which might be added" - I don't think you can modify the system defaults (although I could be wrong - it's not something I've done much).
Computer Configuration-->Windows Settings-->Security Settings-->Event Log
Related
SCCM is the method we deploy Windows updates to clients. We have a portion of computers that have a local group policy setting under:
Local Computer policy > Administrative Templates > Windows Components > Windows update
The setting is called "Specify intranet Microsoft update service location"
Basically the wuahandler.log is complaining of :
Enabling WUA Managed server policy to use server: http://servername.domain.local:8530
Group policy settings were overwritten by a higher authority (Domain Controller) to: Server https://servername.domain.local:8531 and Policy ENABLED
Failed to Add Update Source for WUAgent of type (2) and id ({C2F93D44-EAB3-4D5E-9330-7806157D92AD}). Error = 0x87d00692.
I can see that for whatever reason SCCM is not modifying the local group policy and its causing a conflict.
The pc's that have no issue have both the local group policy and policies under hklm > policies > windows update as the correct name (with port 8531).
I am basically asking how can i change the "specify intranet microsoft update service location ' using powershell or an automated method to remediate the 300 pc's that have a mismatched port number. modifying the HKLM keys under Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate ive already taken care of. But this is not doing anything to resolve my issue.
any help would be appreciated.
There are many articles all over the web on using PowerShell and local policy management. Just search for them. Using a string like 'PowerShell manage local policy' and you will get a long list to consume.
There is even a module via the MS PowershellGallery.com for Local Policy Management.
Find-Module -Name 'PolicyFileEditor' |
Save-Module -Path "$env:USERPROFILE\Documents\WindowsPowerShell\Modules" -Force
Install-Module -Name 'PolicyFileEditor'
And blogged about its use is here:
How to manage Local Group Policy with Powershell
You can even just secedit.
Take a look at this Q&A
So, sure you can mess with Local Policy, be if your SCCM settings getting overridden by a higher authority, then any setting you'd do wit PowerShell would as well.
Please make sure that in case of SCCM/MECM or installations with system user (NT-Authority\System) you do not use -Scope CurrentUser, otherwise you will have the same problem as described here: https://github.com/PowerShell/PowerShellGetv2/issues/651
In a system context Install-Module does not create a Documents folder in the system profile if -Scope CurrentUser is used.
If you want to use -Scope CurrentUser anyway, you have to create the folder "C:\Windows\system32\config\systemprofile\Documents\PowerShell\Modules" or at least "C:\Windows\system32\config\systemprofile\Documents" first, so that the module is installed for the system user.
I'm running a Powershell logon script which sets users' Outlook signatures.
For debugging purposes, I'd like to log information in the client's Windows event log.
Using the New-Eventlog -LogName "Application" -Source $ParentScript command gives me a security error, "Access denied".
The users don't have administrative privileges so PowerShell is struggling to create a new source. I don't really understand this because most techy guides for the Event Log appear to indicate that any level of user can write to the Application log. Perhaps any user can write to this log, just not create a source within it?
I've looked online and one author appeared to suggest (unless I have misinterpreted) that creating an event log in registry could be an option: https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/00a043ae-9ea1-4a55-8b7c-d088a4b08f09/how-do-i-create-an-event-log-source-under-vista?forum=windowsgeneraldevelopmentissues
Unfortunately the code is not in PowerShell and I'm struggling to follow it.
My three-questions-in-one therefore are:
Can I create a new EventLog source in the registry using PowerShell?
If so, what commands should I be looking at and are permissions relevant (e.g. do I need to create a registry key then add perms to it?)
If so, can I write to this source in PowerShell without administrative privileges?
You can create a new Event Log souce with with the built-in cmelt New-EventLog something like there is a nice (even if somehow dated) post here
Full documentation for the cmdlet can be found here
Generally speaking yes you, well your user, should be able to write to the event log if memory serves a non local admin user should already be able to do so but I cannot test it right now anyhow you can red more here or read on server fault
Hope this can help a bit.
I am encountering several situations where, in a Chef recipe with powershell_scipt, a command appears to fail, whereas if I run the same command in powershell outside of Chef, the same command works.
The two in particular are "regedit", which I am trying to use to set a key for app compatibility and the other is "net use z:...." to created a mapped drive. Both of these seem to work fine if I run them in powershell, but if I use them inside a recipe inside powershell_script, they don't appear to do anything.
So I'm wondering is this because Chef runs commands that are inside powershell_script at some lower privilege level?
Also if so, how do I change it so that the regedit and net use would work?
Thanks,
Jim
EDIT 1: This seems to work for adding the registry entry I needed:
registry_key "HKEY_CURRENT_USER\\Software\\Microsoft\\Windows NT\\CurrentVersion\\AppCompatFlags" do
values [{
:name => "{2b9034f3-b661-4d36-a5ef-60ab5a711ace}",
:type => :dword,
:data => 00000004
}]
action :create
end
That prevents the compatability popup that I am getting when we run the Sharepoint installer.
EDIT 2: I hope that this is ok, but for the record and more visibility and hope that I remember this, I found this re. mapping drives in Windows and Chef:
Mount windows shares on a windows node with Chef
and:
https://tickets.opscode.com/browse/CHEF-1267
I haven't tried that yet, but that seems like the answer to my drive mapping need.... hopefully..
The chef client service runs as Local System (SYSTEM) by default.
In Windows, that user has full privileges on the local system, like root basically, but on the network it authenticates as the computer object.
So it you are trying to use regedit to change something in for example HKEY_CURRENT_USER then you need to remember that the code will not see the same "current user" as you will when you run it in interactively. Also, regedit is an .exe; you should really do what you need through the PowerShell providers or .Net objects.
For net use you are trying to map a drive. It's likely that the computer account doesn't have the rights to the share that your user has. Again, net.exe is a separate executable. net use maps a drive to a drive letter (usually) and you shouldn't be doing that in a configuration script, in my opinion. You should access the UNC path directly, but either way I still think that you're probably running into a permissions issue here.
You could change the credentials of the service to use a user account that has all the rights you want, but before doing something like that you should consider changing your workflow to not need that.
I am currently in the process of setting up a DSC pull server using the DSC resource kit wave 8.
Unfortunatelly the module MSFT_xDSCWebService.psm1 has a bug and throws an exception when ever another locale then 'en' is in use.
The exception message tells me it's looking for a file called resource.dll in the wrong place. I have therefor made changes to the module, so it looks in the right place.
However the changes show no effect, even a Write-Host "Test... is not showing up in the output. Is there somekind of cache that needs a refresh?
Make sure that in your Local Configuration Manager (LCM) settings, you set AllowModuleOverwrite to $true.
This may be because DSC has already loaded the previous version of the module - which is in memory. An easy way to refresh is to bring down the DSC process and run the configuration again (do not try this on a production system as other WMI providers are co-hosted with DSC)
gps wmiprvse | ?{$_.modules.ModuleName -ieq 'dsccore.dll'} | kill -Force
Can any script or setting be written (autorun file?) to disable formatting of a USB Flashdrive? (Win XP, via Windows Explorer > Format)
I'm aware of write-protection, but I don't want to completely prevent modifying files, instead something like what a Group Policy setting could do?
Edit: Really what I'm asking for is a registry setting or else that I can modify on USB drive startup to tell Win XP not to format drive X:
Format the things as NTFS. That should give you sufficient security. You need admin rights to the volume to reformat the USB stick. Anyone with those rights can by definition disable any protection you could enable. If you allow Everyone to create and modify files in the root directory and below, users can still write files as demanded.
Registry key 'MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\AllocateDASD' restricts the formatting and ejecting of external drives (see this helpful Microsoft spreadsheet full of registry keys that the Group Policy editor controls).
Set it to 'Administrators' or another group which you can trust not to go formatting where they shouldn't.