With the help of the NuGet package manager, you can easily host an internal PowerShell package source for your organization.
Profile gravatar of Timothy Warner

Timothy Warner

Timothy Warner is a Microsoft Cloud and Datacenter Management Most Valuable Professional (MVP) who is based in Nashville, TN. Check out his Azure and Windows Server video training at Pluralsight, and feel free to reach out to Tim via Twitter.
Profile gravatar of Timothy Warner

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:

  1. 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.
  2. 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.
  3. 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

Heres 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.

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:

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:

Finally, we need to relax the script execution policy on this machine:

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

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

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

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 applicatoin's IIS server settings

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

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

Your private repositorys home page

Click the link I highlighted in the previous screenshot to view your actual package feed:

Here's our feed

Heres 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:

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

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!

Take part in our competition and win $100!


Related Posts

1 Comment
  1. avatar
    OJ 8 months ago


    Very nice post - thank you so much!

    But I'm running into a Problem in my Lab. Everything works fine - until I start install-package. He definitely contacts MyRepo, but then he is downloading the files from live.sysinternals.com.

    My guess would be to edit the $URL in the chocolateyInstall.ps1 in the nupkg. But this seems to be not that easy - at least I'm getting a lot "access denied" when I'm trying...

    Any hints? What do I miss?

    Thanks in advance!


Leave a reply

Your email address will not be published. Required fields are marked *



Please ask IT administration questions in the forum. Any other messages are welcome.

© 4sysops 2006 - 2017

Log in with your credentials


Forgot your details?

Create Account