Installing WAMP on Windows Server 2012

Windows Server 2012 has several different installation types (the minimal “Server Core”, “Minimal Server Interface”, “Server with a GUI”, “Full”), and different options/features to select from.

Some features are required to run WAMP, while others have to be removed.

To be able to install and run Apache, MySQL, and PHP (i.e., WAMP) on Windows Server 2012, these are the minimal options/roles/features:

* .NET 3.5 is not absolutely required, as most .NET 3.5 applications can be ran under .NET 4.5 (i.e., the Windows Server 2012 default .NET verison).

If you have installed “Server Core”, you will need to switch/convert it to “Server with a GUI” (which can be done with a number of commands).

It is best to not have additional Roles installed, such as: “Web Server (IIS)”. As these Roles and Features will have Services and processes that take port 80 and 443, which Apache needs to run (check Disable Services that Interfere with Apache).

You will also need to install the “C++ Re-distributable for Visual Studio 2012″ which contains the DLLs that Apache and PHP are compiled against (check Required Microsoft VC++ Redistributable Packages).

WampDeveloper Pro’s Web-app Auto-Installer Internals

If you are interested in creating your own web-app packages (such as a custom package of WordPress with various themes and plugins integrated and enabled) that are then “one-click” easily (for deployment) and repeatably (for testing) installable to any website and URL, WampDeveloper Pro provides its own web-app packaging format and installation mechanism…

The web-app installer reads and executes commands (that it understands) from an XML file – performing the task of placing, importing, editing, and manipulating web-app assets (files, configuration, database entries). This process creates an “installation” that is [ideally] identical and indistinguishable from a regular install.

The principle difference between WampDeveloper’s web-app installer and the web-app’s native setup/installation process is:

Native setup/installation – runs through the web-app’s PHP code, which forms the database, populates that database, and updates the configuration file.

WampDeveloper’s web-app installer – bypasses the above native process completely by placing the web-app’s files, importing the already formed database, and using the install-to path and URL, updating the configuration and database entries to reflect the new location.

To create a web-app package:

Web-app Assets

Create the needed assets for the installer to start with…

1. Manually install a web-application using these default values:

username: admin
password: passadmin
DB name: webapp
DB user: webapp
DB host:

Technically you can use any values you’d like, but the above will be considered as standard. These values will later be changed by the auto-installer using the selected website, URL, and the generated DB name + user and Admin password.

When installing the web-app, try not to go pass the finish of the installation process – by accessing the home page and/or performing a login. If you do so, the web-app will likely create sessions, caches, temporary files, and database entries, that might need to then be cleaned up.

2. Perform a clean up by deleting any created:

A. Sessions - e.g., truncate table "sessions"
B. Caches - e.g., truncate tables "cache_*"
C. Watchdog (log) - e.g., truncate table "watchdog"
D. Any cache and temps files - e.g.,  files in web-app's "temp" sub-folder

This step is not necessary, but it is considered good to not leave any residual fingerprints and data.

3. Export the web-app’s database into an SQL file, and zip the file as: \database\

4. Select all the web-app’s files (but not the containing folder), and zip the selection as: \files\

5. Copy the web-app’s configuration file(s) into: \configs

Package Format (Example)

All the web-app packages are stored in folder:

If you take a look into folder \WampDeveloper\WebApps\wordpress-\ , next to the base assets, there are three XML files that define and control the installation of WordPress.

All other files/folder within are just things referenced and used by tasks.xml (WampDeveloper only knows about the 3 XML files).

1) tasks.xml: which defines what to do to install the package (and move it to another URL, delete it, etc).

2) parameters.xml: which defines the variables and defaults (such as “db_host” is to be “” / localhost by default), that will be used later in tasks.xml.

3) profile.xml: which just defines the name, version, and some other “info” data about the web-app and package.

Installation Tasks

The way it works is tasks.xml:

a) Imports \database\wordpress.sql(.zip) into MySQL.
b) Imports \files\files(.zip) into the install-to directory.
c) Imports \configs\wp-config.php into the install-to directory (or where WordPress expects to find it).
d) Performs SQL queries to create the proper database name, database user, and update the database with the proper values for the new URL, path, etc.
e) Performs file edits to update wp-config.php with the proper values for DB name + user + host, keys and salts, etc.
f) Runs a script (scripts\setPassword.php) that uses WP’s API (functions) and a passed-in command-line parameter to set the admin password.

Creating Web-app Package

If you have the time to study the format/syntax of the above XML files, you can create your own packages. The difficulty of it is that none of this is fully documented for the moment, as it’s all still evolving. And if it’s not done correctly, it’s just going to fail without providing any type of useful error message.

If you wanted to create your own WordPress package with your additional configuration, content, themes, and plugins included, just install WordPress (and additions) into:\blog. Then, as shown above: export and zip the database, copy the wp-config.php file, zip up the files, and replace those assets within a duplicate of the already provided WP package (i.e., in a copy of the provided webapp-version package – with the folder name updated for version and release number). Afterwards make some minor edits to profile.xml and tasks.xml to reflect the new version and possibly any new changes.


Create auto-installer for the latest version of web-apps such as Wordress.
Create auto-installer for any PHP Framework such as CakePHP, CodeIgniter, Zend.
Create auto-installer for any Frontend HTML + CSS Framework / Template such as Bootstrap.
Create auto-installer for any Javascript MVC Framework or Library such as AngularJS.
Create auto-installer for executable (binary) applications such as Node.JS.
Create auto-installer for an entire website (including its databases).
Create auto-installer for full Windows applications, including IDEs (editors).
Create auto-installer for Mobile Frameworks such as Ionic.

Quick WordPress Multisite (MU) Installation and Setup for Different Domains and Sites

WordPress Multisite (or Network) is 1 wordpress installation that enables hosting of multiple different websites and domain names.

WordPress Multisite uses the same wordpress base (including the themes and plugins), wordpress database, and wp-config.php configuration file – for all sites in the network.

To install and use WP MU (Multisite), you would:

  1. Install WordPress on a base website and domain. This installation will provide for all your MU sites.
  2. Activate (turn on) Multisite / Network:
    1. Edit wp-config.php
      define( 'WP_ALLOW_MULTISITE', true );
    2. Go to Tools > Network Setup, select to use: sub-domains, and provide the asked “network” details (primary: domain, title, mail address). Install.
    3. Make sure the displayed wp-config.php and .htaccess changes are made (and if not made automatically, make edits manually).
  3. Install the “WordPress MU Domain Mapping” plugin to be able to use separate domain names for different sites (otherwise you’ll only be able to use sub-domains for sites, such as:,,
  4. In the website’s settings (or directly in the HTTP and SSL VirtualHost files), add your list of sub-domains and full-domains into the ServerAlias field. Make sure redirects are turned off.
  5. If hosting (i.e., not local dev), you’ll need to make sure that you have proper DNS set up for:
    • Each site’s domain name with a “CNAME” record resolving to the base (primary) domain name.
    • Wildcard (*) on the base (primary) domain’s host (sub-domains) with a “A” record resolving to the server’s IP address.
    • And of course the base domain name resolved to the server’s IP address.
  6. Make sure to clear your Browser’s cookies and cache.

Rotating Apache Logs Daily With RotateLogs.exe

By default, access requests, errors, and some other segmented data, is written into separate log files, which are not rotated by Apache.

These log files grow in size as new log data is appended with each additional access request made. And it’s left to the user to (once in a while) stop Apache, and rotate (i.e., rename) or delete the log files, so everything starts from size-zero again.

Rotating logs is important because once log file sizes reach the 500MB to 1GB range, this can create issues for: Apache (e.g., slow downs), for file editors/readers (such as Notepad), and also for some statistics/analytic programs (such as AWStats).

Standard Logging Configuration

The standard logging configuration can usually be found in each website’s HTTP and SSL VirtualHost files:

ErrorLog "C:/WampDeveloper/Logs/Websites/"
CustomLog "C:/WampDeveloper/Logs/Websites/" combinedtrueout_host
CustomLog "C:/WampDeveloper/Logs/Websites/" deflate

The last part of each line is the name of the log format definition to use. WampDeveloper Pro's log format characteristics are more advanced than the "common" LogFormat, and the definitions are located in configuration file: C:\WampDeveloper\Config\Apache\extra\wampd-logformats.conf

Each line simply creates the specified file, and appends data to it (there is no rotation).

Rotating Logging Configuration

To automatically rotate a website's access.log (and other log files such as the error.log) every 24 hours (daily), Apache's included rotatelogs.exe tool can be used...

With rotatelogs.exe, instead of writing to log files directly, Apache will "pipe" the log data into specific rotatelogs processes. And these rotatelogs processes will keep track of the elapsed time and/or growing file size - and once the specified limit is reached - will rotate their assigned log files (and start new log files).

Replace the standard logging configuration with:

ErrorLog "|bin/rotatelogs.exe -l C:/WampDeveloper/Logs/Websites/ 86400"
CustomLog "|bin/rotatelogs.exe -l C:/WampDeveloper/Logs/Websites/ 86400" combinedtrueout_host
CustomLog "|bin/rotatelogs.exe -l C:/WampDeveloper/Logs/Websites/ 86400" deflate

If you are not using WampDeveloper Pro, but some other WAMP server, replace the LogFormat part (end part) of the access.log CustomLog line with "common".

This will create daily log files:

  • With filename format of http.accesslog.2015-03-14.txt (logfile.year-month-day.txt)
  • Using the computer's local time (not UTC).
  • And a rotation time of midnight.


1. RotateLogs will start 2 processes per log file. With at least 3 log files per VirtualHost (access.log, error.log, deflate.log), and 2 VirtualHosts per website, this can add 12 "rotatelogs.exe" processes to your system for each website that you set up RotateLogs with.

You should only use RotateLogs on your high traffic website, and perhaps only for the access.log file, as otherwise your might run out of memory due "problems when running many piped logger processes on Windows".

2. RotateLogs limits are not exact... It will not make a new log file exactly at midnight, and it can also go over whatever the set file size limit is - due to the way these limits are handled.

3. RotateLogs will only create a log file after the first request is made.

4. Some older Apache versions came with a buggy RotateLogs implementation that would not die after Apache restarted.

5. Apache start error (in error.log):

(OS 2)The system cannot find the file specified. AH00104: unable to start piped log program 'bin/rotatelogs -l C:/WampDeveloper/Logs/Websites/ 86400'

The standard documentation and examples for RotateLogs are no longer correct... On Windows, and with Apache 2.4, you have to specify the full file name of rotatelogs: rotatelogs.exe... CustomLog "|bin/rotatelogs.exe ...

This is not a problem for the above instructions, but is something that you should be aware of for older ones.

Binding Apache to a Specific Or Secondary IP Address

Apache, by default, will attempt to bind to and listen on these interfaces:


1. “” means ALL IPv4 addresses that the system has (including

2. “::” means ALL IPv6 addresses that the system has (including ::1).

When started, Apache will try to take all the IP addresses of the system, and if you are already running another web-server (such as IIS, Tomcat, Nginx, Jetty, Domino, etc) on that same system, Apache will not be able to bind to “” and “::”, and will fail to start. Or, if started first, after binding to all the available IP addresses, it will prevent the other web-server form starting.

To bind Apache to a specific or secondary IP address:

Edit file –

Find and replace these two lines (one is at the beginning, the other at the end) –

Listen 80
Listen 443

With –


You can specify multiple IP addresses with multiple lines.

If this is a public server, make sure that the IP addresses you are using, are either the resolvable IP addresses of your Apache hosted domain names (e.g., the Public IP address), or the LAN IP addresses that the Router is port-forwarding outside port 80 and 443 traffic to.

If this is a intranet server, you can just bind Apache to the LAN IP.

If this is a localhost server, you can just bind Apache to

Also make sure that your other web-server is binding only to a specific IP address, and not to “”.

After making changes, if Apache won’t start, check the configuration by running (from the command line):

httpd -t -n "Apache2"
httpd -k start -n "Apache2"

Upgrading WampDeveloper Simplified

The upgrade process for 95% of WampDeveloper users involves (for the most part) just copying and replacing a few folders and files to keep your previous websites and databases.

The process in the larger WampDeveloper Upgrade guide appears more complicated because it includes additional explanations, takes care of special cases, and describes possible issues (with solutions provided).

This is the simple version of the WampDeveloper Upgrade guide. If you are upgrading between versions within the same major version or branch, and have not made any significant changes to the configuration and the platform, this guide is for you.

Upgrading WampDeveloper

  1. Click uninstall (bottom of Components Tab), proceed.
  2. Rename folder C:\WampDeveloper to C:\WampDeveloper.old
  3. Install new version as C:\WampDeveloper
  4. If you have websites and databases to keep:
    1. Using the Websites Tab, re-create your extra (new) websites (by inputting the same domain name and domain aliases for each website). Then stop Apache and MySQL.
    2. Delete and replace (with previous) folder: \Database
    3. Overwrite / copy-over (with previous) folder: \Websites
    4. Re-install the phpmyadmin database by using (i.e., copy-paste + update for drive letter) and running the 4 commands listed in the section “Re-Install phpMyAdmin’s Database” of the larger guide.
  5. If you used WampDeveloper to auto-install web-apps (via Webapps Tab), to see those web-app installations listed in the Webapps Tab, replace (with previous) file: \Webapps\apps.xml
  6. If you have made custom changes to the website VirtualHost files, website AWStats configuration files, and/or the general Apache, MySQL, and PHP configuration files – those changes should be made again in the new installation.

Error “Warning: mysql_pconnect(): MySQL server has gone away…”

If you are having a reoccurring problem where Mysql refuses connections with the following error message:

Warning: mysql_pconnect(): MySQL server has gone away in C:\WampDeveloper\Websites\\webroot\script\file.php on line X

Note that you are using persistent connections. Persistent connections do not automatically close when the script ends, and likely what is happening is either…

  1. That same persistent connection, is correctly reused each time the script runs, but eventually it does reach its maximum run-time value, and is closed by MySQL. And only after your page is refreshed/reloaded and the script runs again, a new persistent connection is created and everything works again (until the next timeout).
  2. Many persistent connections are created, and after MySQL reaches the maximum number of allowed connections, no new connections are allowed until some of the previous connections timeout. Sometimes this is due to a large number of users (100+) all accessing the script, other times this is due to issues and bugs in the script itself (and there can also be some complications when running PHP-FCGI).

To fix this, you have several different options:

Default to Regular Connections

Tell PHP to silently use non-persistent connections even when persistent connections are specified…

Edit php.ini (C:\WampDeveloper\Config\Php\) and update or add this into the [MySQL] section…

; Allow or prevent persistent links.

This will close each connection when the script ends, regardless if “mysql_pconnect” or “mysql_connect” is used.

Switch to Regular Connections

Don’t use the persistent versions of PHP functions and methods for MySQL connections. Persistent connections are never recommended, and should only be used in special circumstances (because they tend to just cause connection exhaustion while offering no real performance gains).

Instead of “mysql_pconnect” just use “mysql_connect“. Both functions use the same exact API (i.e., parameters), and you can safely search-and-replace all occurrences of “mysql_pconnect(” with “mysql_connect(” in your script files.

Also note that the above functions are depreciated starting with PHP 5.5, and will be removed from PHP in later versions. If you can, switch to using PDO methods.

Increase Max Connections and Timeout Values

Otherwise, increase the number of allowed connections…

Edit my.ini (C:\WampDeveloper\Config\Mysql\) and add this into the [mysqld] section…

Increase the number of MySQL connections allowed:

max_connections = 151

* The above is the default value.

Depending on the situation, decrease the persistent connection timeout value (so those persistent connections are closed and recycled faster):

interactive_timeout = 28800
wait_timeout = 28800

* The above are the default values, in seconds (8 hours).

These settings might not exist in my.ini, you have to add them into the [mysqld] section of the file.

Note that:

1. These are the default values for each setting… If you put them “as-is”, they will have no effect… As those settings + values, even while they might not be present in my.ini, are already set by default by MySQL for itself on each start-up.

2. These values don’t technically fix anything, they just try to mitigate around some underlining problems with connection timeouts caused by issues in the script. They are temporary patchwork (in most cases).

3. Take care setting these values correctly. max_connections might need to be doubled, and/or the timeout value might need to be lowered to 300 (seconds). But if you increase or decrease these values too much, other issues could start happening.

4. Don’t use these settings if they do not fix anything.

5. You’ll need to restart Apache and MySQL after making changes to my.ini and php.ini.