Install Jenkins on Windows Server Core – Part 1

I’ll admit it- I love Windows Server Core and I use it whenever possible. I think everyone should try and do the same. However, I know not everyone is a PowerShell expert or has any desire to be one.

So for this blog post I’m going to show how I created a simple script that will install Jenkins CI on a Windows Server Core system to be a Jenkins Master server. Feel free to just skip down to the end and use the completed script if you want to. I did this on a Windows Server 2012 R2 Core system, but this would probably work on Windows Server 2016 TP4 (the currently available version). You could of course use this on a Windows Server Full system as well.

Note: Installing a Windows Server Core as a Jenkins Slave server is a similar process but there is no need to install the Jenkins Server software or service. I won’t cover the process of installing a Windows Jenkins Slave in this post.

This is post is part one of a two part post. In the part two I’ll convert the process over to a DSC configuration that can be applied to one or more nodes to make the process even easier and ensure your Jenkins servers maintain their state.

Requirements

You’ll need:

  • A physical or virtual machine running Windows Server 2012 R2 Core (or Full) – it should be a completely clean install with nothing already installed.
  • An administrator login to the server.
  • An internet connection to the server.

The Script

The first thing I like to do is get all the variables into one place so I can easily see what options I might want to set. In this case the only thing I care about is setting a static IP Address details of the server and also the port Jenkins will be assigned to:

 

# Configure the settings to use to setup this Jenkins Executor
$Port = 80
$IPAddress = '192.168.1.96'
$SubnetPrefixLength = 24
$DNSServers = @('192.168.1.1')
$DefaultGateway = '192.168.1.1'

The next thing I need to do is ensure the .NET Framework v3.5 is installed (required by Jenkins on Windows):

# Install .NET Framework 3.5
Install-WindowsFeature -Name NET-Framework-Core

For this installation I’m actually going to let the Chocolatey package manager do most of the heavy lifting of actually downloading and installing the Jenkins bits. So I need to install Chocolatey:

# Install Chocolatey
iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))

Next up, I use Chocolatey to install both the Oracle JDK 8 and the Jenkins bits. These will be downloaded off the internet so may take a little while depending on your connection. The -y parameter forces the install to occur without prompting:

# Install Chocolatey
# Install JDK 8
choco install jdk8 -y

# Install Jenkins using Chocolatey
choco install Jenkins -y

What I’m going to do next is configure the port Jenkins should run on. This is done by changing the –httpPort setting in the c:\program files (x86)\Jenkins\Jenkins.xml file. I’ll use a simple RegEx to do this. Also, because the Jenkins Service is already running at this point I’ll need to restart it before the changed setting will be read:

# Set the port Jenkins uses
$Config = Get-Content `
  -Path "${ENV:ProgramFiles(x86)}\Jenkins\Jenkins.xml"
$NewConfig = $Config `
  -replace '--httpPort=[0-9]*\s',"--httpPort=$Port "
Set-Content `
  -Path "${ENV:ProgramFiles(x86)}\Jenkins\Jenkins.xml" `
  -Value $NewConfig `
  -Force
Restart-Service `
  -Name Jenkins

The Chocolatey Jenkins package automatically configures a firewall rule named “Jenkins” that allows inbound traffic to the Java.exe application. This means that external machines will be able to connect to this Jenkins server. You may want to change this by removing the “Jenkins” firewall rule and replace it with something more specific to your needs, however I didn’t do this in my script.

The final section is optional – it just configures the network connection on the machine to use a static IP address. You could omit this section completely if you were using DHCP or some other method of configuring the network connection:

# Set a static IP Address - optional
New-NetIPAddress `
 -IPAddress $IPAddress `
 -InterfaceAlias Ethernet `
 -DefaultGateway $DefaultGateway `
 -AddressFamily IPv4 `
 -PrefixLength $SubnetPrefixLength
Set-DnsClientServerAddress `
 -InterfaceAlias Ethernet `
 -Addresses $DNSServers

That’s all there is to it.

The Complete Script

Here is the complete script. You can just fire up PowerShell on the Core server and copy/paste this directly into the PowerShell console, or use some other method of running it:

Tomorrow I’ll improve on this process by converting it into a DSC configuration, which will ensure the Jenkins Server maintains it’s state and makes provisioning them even easier.

Thanks for reading.

 

 

Advertisements

Disk Cleanup and the joys of Features-on-demand

Features-on-demand – it’s a great new “feature” – when it works. However, the rest of the time it is a real headache.

A couple of months ago I decided I wanted to trim down the size of my Windows Server 2012 R2 VM’s. Disk Cleanup (cleanmgr.exe) is one tool that I’ve often found really useful to have on a server install, especially when preparing OS VM images to ensure the install is as lean and clean as possible.

However, by default the tool isn’t installed on Windows Server 2012. To get access to Disk Cleanup on a server OS you need to install the Desktop Experience feature:

Install Desktop Experience using Add Roles and Features Wizard

Install Desktop Experience using Add Roles and Features Wizard

Because I had used features-on-demand to remove any disabled packages from the system I received a message telling me I might need to specify an alternate location for the source files:

Specify an Alternate Source path

Specify an Alternate Source path

Anyone who has used features-on-demand should be familiar with this:

Desktop Experience Feature-on-demand removed

Desktop Experience Feature-on-demand removed

Because I haven’t got a GPO restricting my servers from downloading updates and packages from Windows Update I thought I wouldn’t have a problem and didn’t need to specify a source.

I was wrong:

Failed to install the Desktop Exprience

Failed to install the Desktop Experience

That is a bit odd – the server has access to Windows Update – it had downloaded updates earlier that day. Other removed features-on-demand features had been installed on this server without an issue, downloading the source files directly from Windows Update. So I was a little puzzled as to why this was different.

No problem, I thought! All that needs to be done is specify a source. In case this is useful, the following TechNet article covers the different ways of specifying a source when installing features that have been removed:

Configure Features on Demand in Windows Server

There are several different sources that can be provided to the Add Roles and Features Wizard:

  • Specify a WIM file (and index) containing the windows installation files for the OS version that was installed on the server. This is usually a file called install.wim that can be found in the Sources folder of the Windows Server2012R2 installation media.

    Install Feature using a WIM source

    Install Feature using a WIM source

  • Specify the windows folder of a working OS install containing the files for this feature. This is usually done by mapping a drive to a share or by mountingaVHD/VHDx file as a drive to the OS.

    Install Feature using a shared Windows Folder on a machine with the Desktop Experience feature installed

    Install Feature using a shared Windows Folder on a machine with the Desktop Experience feature installed

I tried both of the above methods but neither of them seemed to work for the Desktop Experience feature. The same error occurred every time:

Install-Windowsfeature: The request to add or remove features on the specified server failed.
Installation of one or more roles, role services, or features failed.
The source files could not be downloaded.
Use the "source" option to specify the location of the files that are required to restore the feature. For more
information on specifying a source location, see http://go.microsoft.com/fwlink/?LinkId=243077. Error: 0x800f0906

I also tried installing the feature using PowerShell, using no alternative source, using a WIM source and using a Windows folder source:

Install-WindowsFeature -name Desktop-Experience -IncludeAllSubfeature -Restart -Source z:

But each time I received the same error message:

Install Feature with PowerShell and specifing a valid source - failure.

Install Feature with PowerShell and specifying a valid source – failure.

At this point I had all but given up. Luckily I didn’t. I thought I’d give it one last try – but this time instead of using commands from the PowerShell DISM module I’d use DISM.EXE directly:

DISM /online /enable-feature /featurename:DesktopExperience /all /source:z:\

Success! DISM worked!

DISM for the WIN! Back of the net!

DISM for the WIN! Back of the net!

This screenshot and the one above of the PowerShell install-windowsfeature failing to install the feature are from the same machine with the same source mapped.

Z: drive here was mapped to a share of the c:\windows folder of a server that has the Desktop Experience feature correctly installed.

It looks like DISM may operate in a slightly different way to PowerShell DISM Module and the Add Roles and Features Wizard when it comes to installing features.

So, if Add Roles and Features Wizard and PowerShell Install-WindowsFeature fail, try DISM – it might work!

Additional Notes

I have also run into the same problem when installing the AD DS feature on a different server – so I don’t think this is specific to the machine or the feature. It has also occurred on machines that I want to convert from a core install to a gui install.

I have tried installing the feature on a clean install of the OS and it works fine – but as soon as all the latest windows hotfixes for the OS are installed from Windows Update the feature can no longer be installed (if it has been removed).

From my investigation, many other people have experienced this problem with varying degrees of success in solving it. Some have said that patching the WIM file with all the latest hotfixes worked for them – but it didn’t for me (but it did inspire me to write a PowerShell module to ease the WIM patch process – more on this in another post). I was certainly in the “tearing my hair out” group until I randomly tried this.

Also, I did try DISM without specifying a source as well, and it failed with the same error code as the PowerShell did:

Install Feature using DISM fails with no Source specified.

Install Feature using DISM fails with no Source specified.

At first I actually thought the soution was using DISM with the /LimitAccess switch to prevent DISM from using the internet to download the packages, but after further tests it doesn’t seem to make any difference – DISM works with and without this switch. The equivelent to the /LimitAccess switch also doesn’t appear to be available in the PowerShell Install-WindowsFeature cmdlet.

Cleaning Up Windows SxS Folder in Preparation for Imaging

In preparation for releasing an operating system image to be used as a WM template I usually like to perform some “shrinking commands” to make sure the image has as small a foot-print as possible.

All the “shrinking commands” are all command line or PowerShell based because they must also be able to be performed on a Windows Server Core installation.

Remove all Uninstalled Feature Binaries

The first thing I usually do is remove any uninstalled feature binaries (as part of Windows Features on Demand). I’ve covered this in an earlier article here.

Remove Old Service Pack Backup Files

The following command removes any files that were backed up as part of installing a service pack. If you execute this command you won’t be able to uninstall any service packs.

DISM /online /cleanup-image /SPSuperseded
DISM /online /cleanup-image /SPSuperseded

DISM /online /cleanup-image /SPSuperseded

Remove Superceeded Components

This command removes any components in the Windows SxS folder that have been superceeded by newer versions.

Windows Server 2008/2008 R2/2012 and Windows 7/8:

DISM /online /cleanup-image /StartComponentCleanup

Windows Server 2012 R2 and Windows 8.1 (performs some additional optimization):

DISM /online /cleanup-image /StartComponentCleanup /ResetBase
DISM /online /cleanup-image /StartComponentCleanup /ResetBase

DISM /online /cleanup-image /StartComponentCleanup /ResetBase

Installing Windows Server 2012 R2 Core – Additional Tools and Scripts

Although Windows Server Core is a great way of ending up with a slim and trim diet server, it can be a little bit tricky when first getting started configuring it. During my experiments running Server Core VM’s I found that there were a few tools either built into server core or available separately that can help get over this configuration “hump”.

Built-in Tools

  1. SConfig.exe

    SConfig.exe is a built in command line tool (with a simple command line GUI) that allows you to perform some simple configuration tasks on your core installation.

    SConfig.exe

    SConfig.exe

    Some of the functions include:

    1. Renaming the computer
    2. Joining a domain or workgroup
    3. Enabling remote management (Win-RM)
    4. Enabling remote desktop
    5. Installing windows updates
    6. Configure network settings
    7. Change system date/time
    8. Shutdown/reboot server

Other Tools

When installing a new copy of one of the Windows Server Core versions it’s quite useful to install several additional tools that will help manage the server from a command prompt and/or PowerShell console.

  1. Corefig for Windows Server 2012 Core and Hyper-V Server 2012

    Corefig allows you to configure some of the main settings of a Windows Server Core installation as well as installing updates and windows features and roles.

    Corefig PowerShell Application

    Corefig PowerShell Application

  2. Windows Update PowerShell Module

    The Windows Update PowerShell module allows you to install windows updates from a PowerShell command line by executing (after installing the module onto the server):

    Get-WUInstall
  3. Remote Server Administration Tools PowerShell module

    The Remote Server Administration Tools PowerShell module is available as an installable feature on Windows Server Core edition. It needs to be first installed by executing the following command at a PowerShell prompt:

    Add-WindowsFeature -Name 'RSAT-AD-PowerShell' -IncludeAllSubFeature
  4. PowerShell Community Extensions

    The PowerShell Community Extensions project provides various useful PowerShell cmdlets. I always install this onto the server and copy the entire PSCX modules folder:

    c:\Program Files (x86)\PowerShell Community Extensions\Pscx3\

    folder into the system modules folder:

    c:\Program Files\WindowsPowerShell\Modules

    This makes the PSCX module available by the import-module command in PowerShell.