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.
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.
For example, let’s take a URL like https://github.com/MSAdministrator/WriteLogEntry. This URL can be broken down as follows
- MSAdministrator = Owner
- WriteLogEntry = Repository
We also know that we want to download the “master” branch of this repository. The next part is that we need to gather a list of files/paths that we need to download as well. These will be passed as an array of strings to the FilePath parameter.
- Branch = Master (unless you want a different branch)
- FilePath = (Files and paths you want to download)
By default this function will always get the master branch of the repository you are wanting to download, but you can specify a different branch if wanted. Additionally, this function will download the specified files to your user profiles Module Path (C:\users\some_user\Documents\WindowsPowerShell\Modules)
To use this function, you will need to pass the following values as parameters to the function. For example, to download my WriteLogEntry repository you will need to call the function like so:
Get-GithubRepository -Owner MSAdministrator -Repository WriteLogEntry -Verbose -FilePath `
I hope that this function helps some of you who want to quickly download a Github repository without installing or using Git. If you have issues or like this function, please submit issues or fork requests to my Github.
Original Image here:
The 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
If 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.
A “Goal Statement” does not need to be a large body of work, it can simply be a couple of sentences or paragraphs. Personally, I take the Scrum/Kanban approach and use User Stories.
User Stories are typically designed in the following format (there are different styles, but in my experience this the simplest form):
As a <type of user>, I want <goal> so that I <receive benefit>.
Having a defined User Story reduces re-work and ensures that all stakeholders involved agree on the intended uses of this new tool. Agreement on the intended results of this new initiative may not solve the problem completely, but it’s a great start!
At this point, we have not written any scripts, functions, modules, classes, etc. You may want to dive right into writing a POC (Proof of Concept), but I recommend that you hold-off. Once all stakeholders have agreed on our User Story, we should move to the design phase (Part 3 coming soon).
Let’s say that we work on a “Automation Team” in our organization that focuses on building tools to streamline processes for both IT and business teams. We have been tasked with helping the organizations IT managers identify and verify that all Active Directory groups in our Forest have the correct owners associated with them. As we start our requirements gathering phase, we ask all stakeholders to provide our team with agreed upon User Stories. Our team receives the following:
As a manager, I want to know all Active Directory groups owned by myself so I can ensure that they are correct.
As a manager, I want to know all Active Directory groups owned by my employees so that I can ensure that they should have access.
As a manager, I want to know all Active Directory groups that do not have an owner but reside in my Active Directory OU so that I can assign the correct owner.
Now that we have our agreed upon User Stories, we can begin the next phase; designing the “look and feel” of our new tool based on the requirements we have been given. Having a general idea of what our stakeholders are needing reduces our work effort, as well as setting clear expectations that are agreed upon.
Understanding why we need to gather requirements is the first step. The next post in this series I will discuss how you can use Kanban, digitally and manually, to organize our tasks so that you or your team can keep track of the status/progress along the way.
The final post in this series, we will begin designing our code layout. This will help us and our stakeholders understand what parameters need to be present, what objects should be accepted in the pipeline, what return objects should look like, and how the new tool will be used.