Latest posts by Timothy Warner (see all)
- Condusiv’s Diskeeper Server 16 - Proactive server file system fragmentation prevention - Wed, Dec 27 2017
- New features of SIEM tool EventSentry v3.4 - Wed, Dec 20 2017
- Use Just-in-Time Access to protect your Azure VMs - Fri, Dec 15 2017
Personally, I think it’s a great thing that we can programmatically install and manage software packages by using the new Package Management feature in Windows PowerShell v5. Not too long ago, Microsoft made Package Management available to systems running Windows PowerShell v3 and v4.
One concern many IT managers had about PowerShell package management is its seeming reliance on the Chocolatey Gallery. Because the Chocolatey Gallery is a community package source (that is, anyone can contribute software packages), it makes sense that we’d need to be extra careful before downloading software from Chocolatey into our internal networks.
The logical next step, of course, is for us admins to host our own Package Management feed. Before we get into the step-by-step, let me give you the big picture. Building your own private package repository involves the following phases:
- Build Chocolatey packages for the software you want to host. I’ll cover creating Chocolatey packages in another blog post; in the meantime, I think you’ll find this tutorial quite helpful.
- Deploy an IIS web server and ASP.NET web application to host your package feed. In this tutorial, we’ll use Windows Server 2012 R2 and Visual Studio 2015. Don’t worry—we aren’t going to write any C# code! If you don’t have a Visual Studio license, you can download a fully functional 90-day trial from the Visual Studio web site.
- Add your private repo as a package source on all clients. We’ll do this with a single line of PowerShell.
Staging your packages ^
In my lab environment, I have two Chocolatey packages ready to go: Sysinternals and TweetDeck. To be honest, I cheated by downloading the packages with Install-Package on another system and moving the .nupkg files to my server.
Here’s what a Chocolatey package looks like on the inside.
I created a folder named PACKAGES on my E: data drive; that’s where I’ll store all my internally approved packages.
Installing the NuGet package manager ^
Fire up an elevated PowerShell prompt and install the Chocolatey package source. If this is your first time using Package Management, run Find-Package first to trigger the download and installation of the NuGet package manager.
Register-PackageSource -Name chocolatey -Location http://chocolatey.org/api/v2 -Provider PSModule -Verbose
NOTE: The NuGet package manager is a toolset that originally targeted .NET developers who needed a simple way to download and manage software libraries for their projects. The PowerShell Package Management feature (and the Chocolatey provider as well) both rely on NuGet as their underlying “engine.”
Next, we need to install the NuGet package manager for Visual Studio:
Install-Package -Name NuGet.vs -Verbose
The -Verbose option is helpful. If you read the output carefully, you saw that the NuGet tools installation made some calls to the Chocolatey Gallery—hence our need to get Chocolatey installed first. Don’t worry—we’ll be hosting only our own internally approved software in no time!
Now, we need to stand up our IIS server along with ASP.NET 4.5:
Install-WindowsFeature -Name Web-Server,Web-Asp-Net45 -Verbose
Finally, we need to relax the script execution policy on this machine:
Set-ExecutionPolicy -ExecutionPolicy Bypass -Force
Creating our Package Management web application ^
As I said, I’m using Visual Studio Enterprise 2015 (remember that you can download a free 90-day trial). Start Visual Studio, and then click File > New > Project to open the New Project dialog.
Next, type ASP.NET Web Application in the search box (A in the following screenshot) and double-click one of the templates (B). Incidentally, it doesn’t matter which language you choose for your project. I chose C#.
Choosing an ASP.NET web application template
Also, choose a good location for the site (hopefully off the C: drive), and give it a short, meaningful name with no spaces. The project name will be the name of the package source, so think about the name before you commit it.
In Visual Studio, you’ll be given a second option to customize your template; choose the blank one and proceed.
Take a look at the following screen capture and follow along: In the Solution Explorer, right-click References and select Manage NuGet Packages... from the shortcut menu (A).
Next, locate NuGet.Server in the list (B), and then click Install (C).
Installing NuGet server
The Visual Studio interface is seemingly ever-evolving; check out PowerShell MVP Boe Prox’s blog post if you’re running an earlier Visual Studio version.
During the NuGet server installation, you’ll see some confirmation screens; just go ahead and click through them, making sure to save your project changes after all is finished.
Are you still with me? Good. Now, we’ll open our application’s Web.config file (A), find the packagesPath key, and type our local package path (B). The reason we’re doing this is simple: we need to tell our NuGet server where to find our internal software packages!
Connecting our NuGet server to our local package directory
Building the solution ^
Visual Studio is perfectly happy attaching the new ASP.NET web application to an IIS Express instance, but that’s not what we need. Therefore, go back to Solution Explorer, right-click your repo (privaterepo in my case), and select Properties from the shortcut menu.
On the Properties page, navigate to Web and make the following changes:
- Choose Local IIS as your server type.
- Click Create Virtual Directory to change your application URL to http://<servername>/<reponame>.
Make sure to click File > Save Selected Settings to commit your properties changes, and then do a File > Save All for good measure.
Customizing our web application’s IIS server settings
Right-click your repo in the Solution Explorer and click Build. You want to see a success message in the Build window as shown here:
Ah—the sweet smell of success
Testing our new package server ^
Pop open a web browser and point it to your new repository. On my system, the URL is http://mem1/privaterepo. If all goes well, you’ll see the following helpful screen:
Your private repository’s home page
Click the link I highlighted in the previous screenshot to view your actual package feed:
Here’s our feed!
To make sure this new server works as advertised, we’ll mosey over to a Windows 8.1 workstation that’s in the same Active Directory domain as my NuGet server. Here’s that PowerShell “one liner” I mentioned to you earlier:
Register-PackageSource -Name PrivateRepo -Location http://mem1/privaterepo/nuget -ProviderName chocolatey -Trusted -Verbose
If the client doesn’t already have the Chocolatey provider installed, then PowerShell helpfully offers to do that for you.
You know what comes next, right? Yep—let’s install a package!
Installing a package from our own private package source
Next steps ^
Well, there you have it: hosting your very own PowerShell package management feed. You can use the same process to host modules for use with PowerShellGet. Today’s tutorial wouldn’t have been possible without help from the Windows PowerShell team and PowerShell MVP Boe Prox—thanks!
In fact, let me leave you with three helpful sites to help you broaden and deepen your knowledge. Be on the lookout for an upcoming post on building Chocolatey packages!
- Windows PowerShell Blog: Setting Up an Internal PowerShellGet Repository
- Boe Prox’s Learn PowerShell Blog: Setting Up a NuGet Feed for Use with OneGet (today’s PackageManagement module was originally called OneGet)
- As a Consultant Blog: Build Your Own PowerShell Module Repository - ProGet