IIS 7.5 and IIS 8.0 European Hosting

BLOG about IIS 7.5 Hosting, IIS 8.0 Hosting and Its Technology - Dedicated to European Windows Hosting Customer

European IIS 8.5 Hosting - UK :: How to Install Wordpress on Windows Server 2012

clock November 4, 2014 08:56 by author Scott

In this tutorial, I will show you how to install Wordpress on Windows Server 2012 with IIS 8. Assume that you have your own dedicated server and you want to install Wordpress. If you use shared hosting provider, all can be done via one click installation via your hosting provider Control panel, or you can ask your hosting provider to install Wordpress for you. Now, how about if you own your dedicated server and you want to install Wordpress on server?

Configuration

The configuration of IIS 8 is quite easy: you just enable the Web Server role through Server Manager. Please see the screenshot below

Then, please make sure you install PHP Manager, I would recommend you to use http://phpmanager.codeplex.com/. This is good tool and help you to enable and disable PHP extensions.

Installation

To make things easy, you can install and configure PHP quite easily using the Microsoft Web Platform Installer. When you run the Web Platform Installer (Web PI), you can do a quick search for “sql php” and it comes up a few results. When you select “Microsoft Drivers 3.0 for PHP v5.4 for SQL Server in IIS”, which is what we need, all other prerequisites will be automatically installed as well as dependencies (PHP and URL Rewrite for IIS).

After Web PI finishes, you will have PHP installed and configured for use in IIS. Time to do a little test to see if everything is running smoothly. Create a new file under C:\inetpub\wwwroot\ (or wherever your Default Web Site is pointing to) named test.php with the following content:

<?php echo phpinfo(); ?>

This will output information about your PHP configuration (ref: http://php.net/manual/en/function.phpinfo.php).

Time to try it out: navigate to the page (likely http://localhost/test.php). If you are greeted with a screen with purple blocks of information about your PHP configuration, you’re all set and you can skip ahead to the WORDPRESS INSTALLATION section. Chances are you’re going to be greeted with an IIS 403.1 error screen, however, which is due to the fact that the user account that IIS is currently using for the anonymous access to your site doesn’t have the proper privileges to access your wwwroot (or equivalent) folder on disk. This is solved quite easily by granting this user (called IUSR by default) access to the wwwroot folder through Windows Explorer or your other favorite method.

Then, please retry

Wordpress Installation

Now we can start downloading the actual WordPress files and start the installation. First off, grab the latest version (or the version of your choice) of WordPress. We will also need the WP Db Abstraction plugin. After downloading, unblock and unZIP both files in a folder under wwwroot (or your Web Site’s location). Installation of the WP Db Abstraction plugin is quite easy, just follow the steps outlined in the readme.txt:

  • Upload wp-db-abstraction.php and the wp-db-abstraction directory to wp-content/mu-plugins. This should be parallel to your regular plugins directory. If the mu-plugins directory does not exist, you must create it.
  • Put the db.php file from inside the wp-db-abstraction.php directory to wp-content/db.php
  • Visit $your_wordpress_url/wp-content/mu-plugins/wp-db-abstraction/setup-config.php to generate your wp-config.php file

Before you perform the last step, though, go to IIS Manager and enter PHP Manager (it’s located on the Features page of your server under IIS). Scroll down and click the “Enable or disable an extension” link. You need to make sure that php_pdo_sqlsrv.dll and php_sqlsrv.dll are both enabled. You can also go ahead and disable the *mysql*.dll extensions. Here’s my list of enabled extensions:

Now we can visit the setup-config.php page as outlined above. The steps here are quite straightforward, so I’m not going to walk you through them. You will need to create a user on your SQL Server 2012 installation with SQL Server authentication that has access to a database that you also need to create to use for your WordPress installation. 

One note about this process: I had some issues when choosing the default selected “SQL Server using MS PHP driver” and went with the “PDO SqlSrv” option the second time to eliminate these issues.

If the wizard has trouble automatically creating the wp-config.php file, you can either choose to give IUSR write permissions on the folder you created to hold all your WordPress files or you can manually create the file under that folder and paste the output you see on screen in there (I chose the latter). After the wp-config.php file is created, you can start the installation of WordPress by clicking the link on the bottom of the page you’re on.

Wordpress Configuration

After the install, which should only take a minute tops, you are now ready to log in to your WordPress admin dashboard and start configuring it how you’d like. As you can see, there’s a sample post and comment already waiting for you. If your experience is anything like mine, you will notice that when you navigate to the Posts -> All Posts option on the top left of your dashboard you won’t actually see these posts in the list. It took some hunting around the web to figure this out, but apparently there’s a line in the translations.php file of the WP Db Abstraction plugin that’s causing this (thanks to tm3ister on http://sourceforge.net/projects/wp-sqlsrv/forums/forum/1124403/topic/5004241 for figuring this out!). The solution is to manually edit the translate_limit function in the mu-plugins/wp-db-abstraction/translations/sqlsrv/translations.php file:

Change

// Check for true offset
if ( (count($limit_matches) == 5  )  && $limit_matches[1] != '0' ) {
    $true_offset = true;
} elseif ( (count($limit_matches) == 5 )  && $limit_matches[1] == '0' ) {
    $limit_matches[1] = $limit_matches[4];
}

To

// Check for true offset
if ( (count($limit_matches) == 5  )  && $limit_matches[1] != '0' ) {
    $true_offset = true;
} elseif ( (count($limit_matches) >= 5 )  && $limit_matches[1] == '0' ) {
    $limit_matches[1] = $limit_matches[4];
}

The last thing we’re going to configure is Permalinks (or pretty URLs) for our posts. When you navigate to Settings -> Permalinks on the admin dashboard, you’ll see some options to rewrite URLs to be more human and search engine friendly. For now, select Custom Structure and enter/%year%/%monthnum%/%postname%/ in the text field and hit Save Changes. The last step is to create a web.config file in our WordPress folder to rewrite the URLs according to this scheme with IIS URL Rewrite. Create a new web.config file (if you don’t have one already) in the folder you installed WordPress to and copy in the following:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="wordpress" patternSyntax="Wildcard">
          <match url="*" />
          <conditions>
            <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
            <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
          </conditions>
          <action type="Rewrite" url="index.php"/>
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

Done!! Your Wordpress is ready on Windows Server 2012.



European IIS 8.5 Hosting - UK :: Hosting node.js in IIS

clock October 15, 2014 07:40 by author Scott

In this post, I will discuss about hosting node.js application in IIS on Windows using iisnode project. OK, let’s begin.

First thing you need to do is install iisnode project side to get the module and samples installed on your Windows box with IIS7 enabled. The hello world sample consists of two files: hello.js and web.config.
This is the hello.js file from the helloworld sample:

var http = require('http');

http.createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/plain'});
    res.end('Hello, world! [helloworld sample]');
}).listen(process.env.PORT);

You will notice that the only difference between this code and the hello world sample from the front page of http://nodejs.org is in the specification of the listening address for the HTTP server. Since IIS controls the base address for all HTTP listeners, a node.js application must use the listen address provided by the iisnode module through the process.env.PORT environment variable rather than specify its own.

 

The web.config file is required to instruct IIS that the hello.js file contains a node.js application. Otherwise IIS would consider this file to be client side JavaScript and serve it as static content. The web.config designates hello.js as a node.js application by scoping the registration of the handler in the iisnode module to that file only:

<configuration>
 
<system.webServer>
   
<handlers>
     
<add name="iisnode" path="hello.js" verb="*" modules="iisnode" />
   
</handlers>   
 
</system.webServer>
</configuration>

This handler registration allows the same web site to contain other *.js files (e.g. jQuery libraries) that IIS will continue serving as static files.

The Advantages Using iisnode

WebSocket Support

As of version 0.2.x, iisnode supports hosting Websocket applications in IIS 8 on Windows Server 2012 and Windows 8. You can use any standard node.js modules that implement the Websocket protocol, including socket.io.

Scalability on multi-core servers

For every node.js application (e.g. hello.js above), iisnode module can create many node.exe process and load balance traffic between them. The nodeProcessCountPerApplication setting controls the number of node.exe processes that will be created for each node.js application. Each node.exe process can accommodate a configurable number of concurrent requests (maxConcurrentRequestsPerProcess setting). When the overall concurrent active request quota has been reached for an application (maxConcurrentRequestsPerProcess * nodeProcessCountPerApplication ), the iisnode module starts rejecting new HTTP requests with a 503 (Server Too Busy) status code. Requests are dispatched across multiple node.exe processes serving a node.js application with a round-robin load balancing algorithm.

Auto-update

Whenever the JavaScript file with a node.js application changes (as a result of a new deployment), the iismodule will gracefully upgrade to the new version. All node.exe processes running the previous version of the application that are still processing requests are allowed to gracefully finish processing in a configurable time frame (gracefulShutdownTimeout setting). All new requests that arrive after the JavaScript file has been updated are dispatched to a new node.exe process that runs the new version of the application. The watchedFiles setting specifies the list of files iisnode will be watching for changes.

Changes in the JavaScript file are detected regardless if the file resides on a local file system or a UNC share, but the underlying mechanisms are different. In case of a local file system, an OS level directory watching mechanism is used which provides low latency, asynchronous notifications about file changes. In case of files residing on a UNC share, file timestamps are periodically polled for changes with a configurable interval (uncFileChangesPollingInterval setting).

Integrated debugging

With iisnode integrated debugging you can remotely debug node.js application using any WebKit-enabled browser.

Access to logs over HTTP

To help in ‘console.log’ debugging, the iisnode module redirects output generated by node.exe processes to stdout or stderr to a text file. IIS will then serve these files as static textual content over HTTP. Capturing stdout and stderr in files is controlled with a configuration setting (loggingEnabled). If enabled, iisnode module will create a per-application special directory to store the log files. The directory is located next to the *.js file itself and its name is is specifed with the logDirectoryName setting (by default “iisnode”). The directory will then contain several text files with log information as well as an index.html file with a simple list of all log files in that directory. Given that, the logs can be accessed from the browser using HTTP: given a node.js application available at http://mysite.com/foo.js, the log files of the application would by default be located at http://mysite.com/iisnode/index.html.

The logDirectoryName is configurable to allow for obfuscation of the log location in cases when the service is publicly available. In fact, it can be set to a cryptographically secure or otherwise hard to guess string (e.g. GUID) to provide a pragmatic level of logs privacy. For example, by setting logDirectoryName to ‘A526A1F2-4E22-4488-B930-6A71CC7649CD’ logs would be exposed at http://mysite.com/A526A1F2-4E22-4488-B930-6A71CC7649CD/index.html.

Log files are not allowed to grow unbounded. The maxLogFileSizeInKB setting controls the maximum size of an individual log file. When the log grows beyond that limit, iisnode module will stop writing to that file and create a new log file to write to. To avoid unbounded growth of the total number of log files in the logging directory, iisnode enforces two additional quotas. The maxLogFiles setting controls the maximum number of log files that are kept. The maxTotalLogFileSizeInKB controls the maximum total size of all logs files in the logging directory. Whenever any of the quotas are exceeded, iisnode will remove any log files not actively written to in the ascending order of the last write time.

Note that this design of the logging feature allows the node.js application to be scaled out to multiple servers as long as the logging directory resides on a shared network drive.

Side by side with other content types

One of the more interesting benefits of hosting node.js applications in IIS using the iisnode module is support for a variety of content types within a single web site. Next to a node.js application one can host static HTLM files, client side JavaScript scripts, PHP scripts, ASP.NET applications, WCF services, and other types of content IIS supports. Just like the iisnode module handles node.js applications in a particular site, other content types will be handled by the registered IIS handlers.

Indicating which files within a web site are node.js applications and should be handled by the iisnode module is done by registring the iinode handler for those files in web.config. In the simplest form, one can register the iisnode module for a single *.js file in a web site using the ‘path’ attribute of the ‘add’ element of the handler collection:

<configuration>
 
<system.webServer>
   
<handlers>
     
<add name="iisnode" path="hello.js" verb="*" modules="iisnode" />
   
</handlers>
 
</system.webServer>
</configuration>

Alternatively, one can decide that all files in a particular directory are supposed to be treated as node.js applications. A web.config using the <location> element can be used to achieve such configuration:

<configuration>
 
<location path="nodejsapps">
   
<system.webServer>
     
<handlers>
       
<add name="iisnode" path="*.js" verb="*" modules="iisnode" />
     
</handlers>  
   
</system.webServer>
 
</location>
</configuration>

One other approach one can employ is to differentiate node.js applications from client side JavaScript scripts by assigning a file name extension to node.js applications other than *.js, e.g. *.njs. This allows a global iisnode handler registration that may apply across all  sites on a given machine, since the *.njs extension is unique:

<configuration>
 
<system.webServer>
   
<handlers>
     
<add name="iisnode" path="*.njs" verb="*" modules="iisnode" />
   
</handlers>   
 
</system.webServer>
</configuration>

Output caching

IIS output caching mechanism allows you to greatly improve the throughput of a node.js application hosted in iisnode if the content you serve can be cached for a time period even as short as 1 second. When IIS output caching is enabled, IIS will capture the HTTP response generated by the node.js application and use it to respond to similar HTTP requests that arrive within a preconfigured time window. This mechanism is extremely efficient, especially if kernel level output caching is enabled.

URL Rewriting

The iisnode module composes very well with the URL Rewriting module for IIS. URL rewriting allows you to normalize the URL space of the application and decide which IIS handlers are responsible for which parts of the URL space. For example, you can use URL rewriting to serve static content using the IIS’es native static content handler (which is a more efficient way of doing it that serving static content from node.js), while only letting iisnode handle the dynamic content.

You will want to use URL rewriting for majority of node.js web site applications deployed to iisnode, in particular those using the express framework or other MVC frameworks.

Minimal changes to existing HTTP node.js application code

It has been the aspiration for iisnode to not require extensive changes to existing, self-hosted node.js HTTP applications. To that end, most applications will only require a change in the specification of the listen address for the HTTP server, since that address is assigned by the IIS as opposed to left for the application to choose. The iisnode module will pass the listen address to the node.exe worker process in the PORT environment variable, and the application can read it from process.env.PORT:

var http = require('http');

http.createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/plain'});
    res.end('I am listening on ' + process.env.PORT);
}).listen(process.env.PORT); 

If you access the endpoint created by the application above, you will notice the application is actually listening on a named pipe address. This is because the iisnode module uses HTTP over named pipes as a communication mechanism between the module and the worker node.exe process. One implication of this is HTTPS applications will need to be refactored to use HTTP instead of HTTPS. For those applications, HTTPS can be configured and managed at the IIS level itself.

Configuration with YAML or web.config

The iisnode module allows many of the configuration options to be adjusted using the iisnode.yml file or the system.webServer/iisnode section of web.config. Settings in the iisnode.yml file, if present, take precedence over settings in the web.config. Below is the list of options (most of which were described above) with their default values.

# The optional iisnode.yml file provides overrides of
# the iisnode configuration settings specified in web.config.

node_env: production
nodeProcessCommandLine: "c:\program files\nodejs\node.exe"
nodeProcessCountPerApplication: 1
maxConcurrentRequestsPerProcess: 1024
maxNamedPipeConnectionRetry: 100
namedPipeConnectionRetryDelay: 250
maxNamedPipeConnectionPoolSize: 512
maxNamedPipePooledConnectionAge: 30000
asyncCompletionThreadCount: 0
initialRequestBufferSize: 4096
maxRequestBufferSize: 65536
watchedFiles: *.js;iisnode.yml
uncFileChangesPollingInterval: 5000
gracefulShutdownTimeout: 60000
loggingEnabled: true
logDirectoryName: iisnode
debuggingEnabled: true
debuggerPortRange: 5058-6058
debuggerPathSegment: debug
maxLogFileSizeInKB: 128
maxTotalLogFileSizeInKB: 1024
maxLogFiles: 20
devErrorsEnabled: true
flushResponse: false
enableXFF: false
promoteServerVars:

Configuration using environment variables

In addition to using web.config and iisnode.yml, you can also configure iisnode by setting environment variables of the IIS worker process. Every setting available in iisnode.yml can also be controlled with environment variables. This option is useful for hosting providers wishing to offer a web based management experience for iisnode.

Integrated management experience

The iisnode module configuration system is integrated with IIS configuration which allows common IIS management tools to be used to manipulate it. In particular, the appcmd.exe management tool that ships with IIS can be used to augment the iismodule configuration. For example, to set the maxProcessCountPerApplication value to 2 for the “Default Web Site/node” application, one can issue the following command:

%systemroot%\system32\inetsrv\appcmd.exe set config "Default Web Site/node" -section:iisnode /maxProcessCountPerApplication:2

This allows for scripting the configuration of node.js applications deployed to IIS.



European IIS 8.5 Hosting – HostForLIFE.eu :: How to Redirect HTTP to HTTPS in IIS

clock August 6, 2014 08:25 by author Onit

Prerequisite

If you are using SSL on your IIS 8.5 (from 7.5 or greater) server for some time now; to get here you had to do a few things:

  1. You scrubbed your site content to ensure all URLs are using their relative form, e.g. “src=’//images\image.png” or explicitly reference the use of HTTPS.
  2. You have tested for certificate and SSL related problems like mixed content, appropriately tagging cookies as secure.
  3. You have ensured that you follow the best practices guidance for SSL server configuration and verified you get an A on  SSLLabs.

there are a few things left for you to do, the most obvious being redirecting all traffic to the SSL version of your site! You should probably monitor your CPU usage during your peak so to ensure you have some headroom. This isn’t likely to be a problem as most web-servers are not CPU bound but it’s always good to check.

 

Once you know you are OK then it’s just a matter of deciding which approach to use, you have two choices:

  1. Dynamically rewriting via code in your ASPX pages
  2. Using the IIS URL Rewrite  module

If you are familiar with the IIS configuration you’re probably asking yourself what about the “Require secure channel (SSL)” option in the IIS MMC? Unfortunately this doesn’t do redirecting it only requires the use of SSL on a given site/folder/file.

So how do you decide which approach to use? The answer to that question is dependent on both your environment and personal preference, but this time we will show how to do using the method two

IIS URL Rewrite Module

since in this article we will showed you to use the second choice, using the IIS URL Rewrite module, you can check the steps below

This approach has a number of benefits, for one having this module allows you to leverage remapping for other purposes also for example maintaining old links that have SEO value. From a security standpoint it’s also a good approach as it keeps this decision one of policy that is enforced in a central place.

To use the URL rewrite approach you will need to do the following:

  1. Install the URL Rewrite module (x86, x64).
  2. Add a rule to rewrite all HTTP URLs to HTTPS.
    1. Open your “web.config” with your favorite editor.
    2. Find the “configuration\system.webserver\rewrite\rules” section.
    3. Add the following text block:
      <rule name=”Redirect to HTTPS” stopProcessing=”true”>
      <match url=”(.*)” />
      <conditions>
      <add input=”{HTTPS}” pattern=”^OFF$” />
      </conditions>
      <action type=”Redirect” url=”https://{HTTP_HOST}/{R:1}” redirectType=”Permanent” />
      </rule>
  3. Restart IIS

Now you can go to your website over HTTP and you will see you are redirected to the HTTPS instance of the site.



About HostForLIFE.eu

HostForLIFE.eu is European Windows Hosting Provider which focuses on Windows Platform only. We deliver on-demand hosting solutions including Shared hosting, Reseller Hosting, Cloud Hosting, Dedicated Servers, and IT as a Service for companies of all sizes.

We have offered the latest Windows 2016 Hosting, ASP.NET Core 2.2.1 Hosting, ASP.NET MVC 6 Hosting and SQL 2017 Hosting.


Tag cloud

Sign in