Few PowerShell Functions Around Windows Security

As parts of the PowerShell project that I’m currently working on, with the help with other people’s contribution in various forums and blogs, I have produced few PowerShell functions around Windows security: Validate Credential Usage: Get Current User Name Usage: Check If Current User has Local Admin Rights Usage: Check if a user is a member of a group Usage: Get Local Machine’s SID Usage: Check If an account is a domain account (as opposed to local account) Note: This function also requires the Get-LocalMachineSID function listed above Usage:

Powershell: Prevent Users To View and Change Input or Config Files That Are Used by a Script

Often, I use .xml or .ini files to store settings that a PowerShell script uses. When I distribute my scripts to end users, sometimes, I want to make sure users cannot manually view or change the content of these config files. Below is what I did to achieve the goal: Create a password protected zip file that contains the config file (.xml or .ini). rename the zip file from xxxxxx.zip to xxxxxx.bin In powershell script, use ICSharpCode.SharpZipLib.dll to unzip renamed zip file compile powershell script to exe so users cannot view the script to figure out the zip file password.

Using SCOM PowerShell Snap-in and SDK client with a PowerShell Remote Session

Recently, I’ve been working on a utility based on PowerShell scripts using WinForms GUI to perform some SCOM tasks (i.e. create maintenance window, approve manually installed agents, adding network devices, etc.). Since this script is going to be widely used in the organisation when it’s completed, I’ve always kept in mind that when users run this utility, the utility should only connect to SCOM SDK service when required and disconnect as soon as the task is done. In another word, I don’t want this utility to remain connected to the SDK service because Microsoft recommends the concurrent connections should not

My Observation on SCCM Clients BITS Settings

Yesterday, while we were reviewing the SCCM (2007 R3) client BITS settings at work, we (my team) have some interesting findings with SCCM client’s BITS settings. We found when the BITS bandwidth throttling settings are configured for a SCCM primary site. SCCM clients get the policy and write the settings into Windows local policy: SCCM Computer Client Agent BITS Settings: BITS Settings from SCCM Client’s Windows local policy (Local Policy –>Computer Configuration –>Administrative Templates –>Network –>Background Intelligent Transfer Service (BITS) –>Limit the maximum network bandwidth for BITS background transfers): As you can see, the SCCM site setting is identical to

%d bloggers like this: