In this blog post I will explain why to automate installations of Windows applications and how you can do this.
Why automate the installation of applications?
But first, why is this useful? Well this depends on your situation and there are probably many good reasons. For me though, it basically boils down to this:
- I often reinstall my computers with new (preview) versions of Windows operating systems and having to install applications each time is a waste of time. Also sometimes you forget to install some things.
- On a regular basis, friends and family either want me to install or upgrade their PC and I want to provide them with a standard set of programs that most people need/want without having to spend a lot of time on it. By example virus scanner, burning program, media player, codecs, etc.
- I want to update existing installed applications to the latest (and hopefully more secure and feature packed) versions.
- When installing applications, there are often checkboxes enabled to install other applications (you generally don’t want to install). Automated solutions using packages generally prevent these additional unwanted applications from installing.
Which tools to use to automate the installation of applications?
Before PowerShell 5 preview was released, I used both Ninite and Chocolatey to perform to automate installations. They both have their advantages as described on this wiki page.
The PowerShell 5 preview version of OneGet installs and searches software from Chocolatey repositories, but support of additional repositories will come in subsequent versions.
How to automate the installation of applications using PowerShell 5 preview?
To automate the installation of applications a couple of things are required:
- You need to determine which applications you want to install automatically.
- You need to determine the package name that Chocolatey uses for this application. Options include:
-Using a browser to browse the Chocolatey packages
-Using PowerShell and a part of the name of the application you’re looking for. By example if you’re looking for Irfanview, use:
Find-Package -Name “fan”
- Store the package names to install somewhere (e.g. in a .txt file on OneDrive for easy access). My .txt file by example includes:
AdobeReader
Directx
ffdshow
Flashplayerplugin
GoogleChrome
Imgburn
IrfanView
Javaruntime
Keepassx
Mp3tag
mpc-hc
PDFCreator
Silverlight
TeamViewer
Totalcommander
Winrar
greenshot
- Use the Install-Package cmdlet to install all the packages whose name is in the file from step 3.
Install-Package -Name (Get-Content C:\OneDrive\AppsToInstall.txt) -Confirm:$False
- Wait for the programs to install
My opinion
It’s great to be able to use PowerShell to install my list of favorite applications similar to like I did with Chocolatey and I’m also looking forward to see what benefits the additional repositories will bring in the future.
I did encounter some errors however while trying to install some applications like Firefox and dotnet3.5. But since it’s still a preview, this will probably be fixed.
For regular users, I think they are better off sticking to by example Ninite because they’re often afraid of anything that involves a CLI.
Blog posts by other people about OneGet
Some other people have also blogged about the OneGet module and have gone in more technical detail, so be sure to take a look at their posts as well:
More information about PowerShell 5 Preview including a download link
Windows Management Framework v5 preview, includes also Desired State Configuration (DSC) improvements and NetworkSwitch commandlets to manage network switches that pass the Certified for Windows Program. For more information including a download link, you can read the initial blog post. : Windows Management Framework V5 Preview
Like this:
Like Loading...
Tags: application, automate, automation, Chocolatey, CLI, installation, Ninite, Powershell, Script
One of the least favorite tasks of many administrators is to document. Good administrators also don’t want to manually do things when it can be automated. This is where Active Directory Topology Diagrammer (ADTD) can help to automate documenting your Active Directory environment.
Recently I have been working on a new Active Directory OU design and used the Active Directory Topology Diagrammer to create a Visio diagram for the AS-IS situation. I have to say it worked great. Keep in mind though that it will show the OUs and not any other containers.
Besides documenting AD OUs, the Active Directory Topology Diagrammer can document many other things as well. Take a look at the article “How To Use The Active Directory Topology Diagrammer” or play around with it yourself to see what it can do.
The tool can also be very helpful when:
- You’re in a new environment and need to get a quick overview of the Active Directory.
- When there’s no documentation available or when the available documentation is outdated.
- When you’re auditing the quality of documentation.
For more tools, take a look at my website: http://bjornhouben-web.sharepoint.com/Lists/Applications/Summary.aspx
Like this:
Like Loading...
Tags: Active Directory, Active Directory Topology Diagrammer, AD, ADTD, automate, automation, Diagram, document, document active directory, document AD, documentation, Microsoft, tool, Visio, Windows, Windows Server
About 6-7 years ago at school we were taught how to script using VBscript. I was really bad at it though and never really made an effort to change that. When PowerShell became more popular however I had gained some working experience and was also pleasantly surprised by the simplicity of it.
I started learning about PowerShell scripting by googling and using script examples. Disadvantages of this approach however is that:
- You can pick up bad habits from others (without realizing it).
- You sometimes don’t know exactly why you’re doing things a specific way.
- You sometimes don’t know why some things are/aren’t working.
PowerShell is getting increasingly important though:
- Even though more companies are offshoring and employees are relatively, it is still cheaper to automate instead.
- Cost isn’t the only issue, speed is important as well. Scripting allows you to get things done more quickly.
- PowerShell is increasingly being adopted by more companies, products and (cloud) services.
- The number of available built-in cmdlets are increasing, which makes it even easier to automate actions.
- For many products you have to use PowerShell to make specific settings, because only the more basic settings are available in a Graphical User Interface (GUI).
- Changes can be applied consistently in a development, test, acceptance, pre-production, production environment.
- Less chance of human error.
- If done correctly, you’ll also have included a way to quickly revert the changes by script.
To make sure I didn’t miss out on too many things, I decided to start with a book that teaches the basics. Because of the good reputation of the authors Don Jones and Jefferey D. Hicks in the PowerShell community, I decided to go for their book “Learn Windows PowerShell 3 in a month of lunches, second edition” published by Manning Publications Co.
The book’s purposely didn’t try to stuff all PowerShell related information into the book. Instead it provided the reader/student with the basics needed to be able to find/discover this information themselves if needed. I personally like this approach, because otherwise there would be too much information to take in which might be demotivating and distracting.
I also liked the practical examples of common mistakes made by people who are new to PowerShell. There were a lot of examples I ran into as well when I started using PowerShell and I think this will prevent people from becoming frustrated because they understand why things aren’t working the way they might have expected.
All in all this is a great book to start learning PowerShell. This is however just the start and you should expect to continue using other resources/books to further your knowledge. The book also provides links to useful resources as well. And most importantly … start using PowerShell more so you will learn by experience.
Personally I still have these books lying around, but haven’t decided yet which one to start with next:
I’m also still considering taking a PowerShell course, but I’m a bit hesitant about the added value because it’s hard to determine the quality of a course by the description.
If you have experiences or suggestions, please let me know.
Like this:
Like Loading...
Tags: automate, automation, Don Jones, Jefferey D. Hicks, learn, Learn PowerShell toolmaking in a month of lunches, offshore, Powershell, Scripting, Windows PowerShell
I run Winaudit on each server/system and save it to a central location named <computername>.csv This way I have access to a lot of information about each system. If you need a specific subset of information for each system however, you don’t want to have to open each file manually to get this information.
This script will parse each <computername>.csv to extract specifc information and save it to one new file containing this info for all parsed separate files.
Like this:
Like Loading...
Tags: Audit, automate, automation, csv, Microsoft, Parse, Powershell, Script, system, System Info, System information, WinAudit
This script determines the group membership of Active Directory users.
In this case, some users are member of multiple functional groups (groupname “*-core”), while the design assumes a user can only be a member a single functional group. This script helps determine the functional groups they are a member of.
Especially with a large number of users, scripting will save you a lot of time.
Like this:
Like Loading...
Tags: Active Directory, Active Directory Directory Services, AD User, ADDS, automate, Directory Services, group, group membership, groups, ICT, Microsoft, Powershell, Script, user, users
In the first part of this LAB setup guide, I described the hardware selection process.
In the second part, I described the hypervisor selection and installation.
In the third part, I described VM guest considerations and preparations.
In the fourth part, I described Configuring Server 2012 VM as DC with DNS and DHCP using PowerShell
In the fifth part, I described easily creating (many) proper AD users with PowerShell
In this post I will describe creating a local PowerShell v3 Help Repository.
First of all, let me explain what a local PowerShell v3 Help Repository is and why you might want it. With PowerShell v3 not all help files are included. You can however always selectively download the latest versions of the help files (for specific commands). This saves space and also makes for a more flexible system where help files can be updated more easily.
Downloading the updates to the help files requires an internet connection however, and this might not be possible or desirable in many situations. Also if every server would download these files from the internet, this would waste internet bandwidth. Microsoft realizes this and provides you with the option to create a local PowerShell v3 Help Repository.
My script to create this local PowerShell v3 Help Repository can be found here. The basic steps include:
- Create a folder where the Help files will be stored.
- Share the folder.
- Create a scheduled task to daily update the help files in .the share
- Create a file in the share that contains the command that needs to be run from another server to update its help files using the local repository (so you don’t have to remember the command).
As stated in step 4, you can manually update the help files. Personally I prefer creating a GPO that creates a scheduled task on every other system to update the help files on a regular basis using the local repository share you just made. This way when you need the help files, you don’t have to wait until the update has been completed and you also don’t have to rely on internet access.
Personally I would have preferred it if Microsoft also offered an option to deploy the help file updates using WSUS. But for now, this will have to do.
Like this:
Like Loading...
Tags: account, automate, help, help files, Help Repository, ICT, lab, Powershell, Powershell 3.0, Powershell v3, scheduled task, Script, share, update, update help files, Update-help
In the first part of this LAB setup guide, I described the hardware selection process.
In the second part, I described the hypervisor selection and installation.
In the third part, I described VM guest considerations and preparations.
In the fourth part, I described Configuring Server 2012 VM as DC with DNS and DHCP using PowerShell
In this post I want to share with you this great blog post “How to use PowerShell to populate Active Directory with plenty enough users for SharePoint” by Wictor Wilén – SharePoint MCA, MCM and MVP.
What you basically do is:
- Use http://www.fakenamegenerator.com to create x number of users from countries you specify and containing fields/data that you specify. This will be sent by mail for free as a .csv
- Use PowerShell to import the CSV and create the user accounts in AD.
What I like about the method is that besides creating many users, it also uses user data that you could encounter in real-life. Also you can modify the user data to more closely match your desired environment. By example by specifying that you want to have Dutch and US names only. For testing purposes, it can be good to include names with strange characters as well, because when these work well …. chances are that everything works well.
[UPDATE 25-01-2014]
Since there were some issues with the original source, I decided to store a cached version as PDF as well (just in case) : How to use PowerShell to populate Active Directory with plenty enough users for SharePoint
It is best to visit the original site though, if it’s available.
[UPDATE 25-01-2014]
[UPDATE 24-03-2016]
An alternative method is displayed here: https://gallery.technet.microsoft.com/scriptcenter/Create-Real-Fake-Names-e1635ef4
[UPDATE 24-03-2016]
Like this:
Like Loading...
Tags: account, Active Directory, Active Directory Domain Services, AD DS, automate, DC, Domain Controller, fake name generator, ICT, lab, name generator, Powershell, Script, user, user data
In the first part of this LAB setup guide, I described the hardware selection process.
In the second part, I described the hypervisor selection and installation.
In the third part, I described VM guest considerations and preparations.
In this post I cover quickly configuring a Server 2012 VM as DC with DNS and DHCP by using PowerShell.
The steps I do take less than 10 minutes in my test lab now. Here’s a short description:
- Create a VM that uses your previously made parent disk.
- Configure the server name and IP addressing and reboot the computer.
- Install AD DS (domain controller) including DNS forward lookup zone and reboot the computer.
- Configure AD and DNS : Enable AD Recycle Bin, Add DNS forwarder, add DNS reverse lookup zone, create DNS PTR record for DC.
- Install + configure DHCP : Install DHCP, Add scope, configure scope, authorize DHCP server in AD.
The scripts I’ve created for steps 2 to 5 can be found here and are based on the great work Stefan Stranger already did in his blog post Installing a new OpsMgr 2012 (SP1) environment the fast way. I added some stuff of my own so it would meet my needs and I tried to keep it as generic as possible so other people can re-use my code as well.
PS: In step 2, IP addressing is not in place yet. To get scripts tot the system, consider:
- Putting the scripts in an ISO file that you can mount.
- Opening Hyper-V Virtual Machine Connection to VM and using “Clipboard”, “Type Clipboard Text”.
Like this:
Like Loading...
Tags: Active Directory, Active Directory Domain Services, AD DS, automate, configuration, DC, DHCP, DNS, Domain Controller, Domain Naming System, Dynamic Host Configuration Protocol, forward lookup zone, forwarder, Hyper-V, hypervisor, ICT, installation, lab, Powershell, reverse lookup zone, Script, Virtual Machine, virtualization, VM
blog.bjornhouben.com 