To run a PowerShell script on multiple computers via Group Policy, you can work with an Immediate Scheduled Task. The main advantage over logon scripts is that you can execute your script with admin rights.
Group Policy allows you to add and remove users to an Active Directory (AD) group. Using this feature improves security because you can ensure that high-risk security groups only contain the users that you specify via Group Policy.
Have you ever needed to download code or a repository from Github, but didn’t want to download and install Git on a machine, create an SSH key, etc. If so, I have something that you may like.
You can find the entire function here: https://github.com/MSAdministrator/GetGithubRepository
To use this function, you will need to know the path to the Github repository (of course) you want to download. Once you have that URL, you will need to pass each piece of the URL into a parameter on the function.
Continue readingAs I discussed in my previous post, you can log information to a file, but sometimes you may want to log to the Windows Event Log. To log to the Windows Event Log, you will need to use the following cmdlets:
Read MoreThe PowerShell function Write-LogEntry described in this post allows you to integrate logging in your scripts in a standardized way. This will help you and your script users to troubleshoot and understand the output. Read More
The first post in this three-part series focused on gathering requirements before spending time coding. While it is not necessary, I recommend that everyone read part 1 (Gathering Requirements). Understanding and having clear “User Stories” outlining the intended purpose of a tool is crucial, especially as we move towards building our new tool.
Once our “User Stories” have been defined and agreed upon by all stakeholders, we then need to begin breaking them down into tasks. There are many different methodologies that allow us to track these different tasks. Part 2 of this three-part series will focus on one of them; Kanban.
Continue readingIf you have worked in IT for any duration, I’m sure you have overheard or been asked to build a tool to complete X or Y. Creating tools with PowerShell is fun, but it can become daunting when you create a tool that does not meet its intended purpose. Without understanding the full requirements, you may waste time and energy on developing a tool that no one will use.
Creating tools with PowerShell to automate a manual process or to help an internal stakeholder accomplish a desired result, typically does not need to turn into a large initiative with a Project Manager or Project Management Office (PMO). Being tasked with creating these tools usually comes in the form a short conversation or through an email. Out of habit, we usually dive right into writing a script or function to solve the problem. This approach can cause a lot of re-work or redesign of our tool once complete. Even though we believe we understand all the requirements, it is better to have the stakeholder create a “Goal Statement” that defines the intended purpose of the tool. The “Goal Statement” helps everyone involved understand when the initiative is done.
Continue reading