Sams Blog

With a lot of computer functionality moving to the “cloud” I was thinking about the future of personal computing as technology diverges and improves. My prediction is that smart phones eventually will become our TV’s, media Stations and desktop PC’s, they will be so powerful that they will be able to provide all our entertainment and computing needs in a portable and compact package.

Obviously we wont want to be squinting at a little smartphone screen to watch the latest film or typing a long essay using a thumb keypad so around the house we will have phone docks that hold the connectors for keyboards and mice and outputs to monitors or our massive wide screen tvs.

Our phones have become our media centres, personal computers and communications devices and we carry them around with us wherever we go. How cool would it be to be able to dock your smartphone at your mates house and have all of your media, games, data etc available to you as if you were at home.

I see this just on the horizon, all the components are there, they just need to improve a little more and it could be a reality very soon.

If you wish to host a domain purchased at another domain registrar with us and you don’t wish to (or can’t) transfer the domain to us, then you can instead set the domain to use our “name servers” which will allow you to have full control over DNS records using our control panels.

Unfortunately this isn’t always the simplest thing to do and we do see a number of common problems with setting name servers. Below I will explain some of the common mistakes made.

The setting of NS (Name Server) records for a second level domain like “servwise.com” is done in the DNS records of the parent domain which for a second level domains is actualy a TLD (Top Level Domain) like “.com” or ccTLD (Country Code Top Level Domain) like “.uk” or “.it”.

For third level domains like “hosting.servwise.com” assigning NS is done at the parent domains DNS which in this case is the second level domain and so the NS records of “hosting.servwise.com” are set in the DNS records of “servwise.com”, for forth level it is set in the third level, and so on and so on.

A common mistake we see are users setting “NS” records for their domain in their own domains DNS records. All this will do is to break DNS as these records need to match the NS records at the parent domains DNS and in fact since the aim is to change the DNS servers used by the domain, setting NS records in the current DNS servers is pointless in any case.

On most domain registrars websites the page for setting name server records of a domain will be separate from the page for setting DNS records of the domain. Sometimes you may even have to request the change through a support ticket with that registrar.

The only time NS records are added or edited in your own DNS is when assigning DNS authority for a sub-domain to another DNS server otherwise they should be left alone.

A good tool we use all the time for checking the DNS structure is valid and working is http://www.intodns.com, It provides valuable information about your DNS settings and if you find anything highlighted in red you know you have a problem.

Looking for our Name servers go to https://www.servwise.com/en/knowledgebase/79/Our-DNS-servers.html

Happy hosting.

As some of you may know DotNetPanel (DNP) who are the authors of our excellent Windows Control panel have recently decided to make their software Open-Source. With this change also comes a name change and the panel is now called WebSite Panel (WSP). In our opinion this is a great news and will allow the software to add many more features and reach a much larger audience. You won’t notice much if any changes other than main logo with no loss of functionality.

The other big news which we know a few of you have been looking forward too, is the addition of .NET v4 to our Windows servers, which can now be chosen from the website/extensions area of the control panel.

I just had a fun night making some changes to one of our Windows Servers, the update was to add some great new functionality to our control panel (DotNetPanel) and also to make sure the server was fully up to date.

The update started great, install software and the obligatory reboot that MS makes you do (Always a heart stopping moment). Machine came back and all looked good initially. Went to test some of the sites on the server and all seemed okay until I tried my own blog and realised that for some reason the permalinks were not functioning properly! quick check of some other blogs and the same deal, the PATHINFO based permalinks (links that include a /index.php/ path in) were FUBARed just returning a 404 error.

First check was file permissions as this can be a common cause of php errors, nothing I tried made a difference, next was checking the PHP.ini config, nope not helping, next was IIS, nothing wrong there, then it was my browser, maybe something wrong with cookies or cache…. nope.  I was stumped….. lots of checking and rechecking later and I still couldn’t understand why  the permalinks  weren’t working…. A number of hours later and I’ve almost given up, a report of a magento site having problems accessing there admin (Yes you heard correct Magento works on our Windows server :0), or at least had been up until a few hours ago).

Went of to check why and noticed a similarity to the WordPress problem, the Magento admin also uses urls with /index.php/ in and although they were being redirected back to the homepage rather than showing a 404 it was still a coincidence..

Now these sites were in completely separate IIS processes and paths so permissions and IIS seemed like a dead end so I was still none the wiser other than knowing it was a server wide issue not localised to a specific path.

After more hours of head scratching I decided to check out the new features I had installed to see if something there might of caused such a strange problem, with the upgrade we gained some new security tools one of them being the new URLSCAN tool from Microsoft which has a number security benefits, it dawned on me that maybe this had something to do with the issue, typically you would expect these things to install disabled until you are ready to enable them.

Well to cut a long tiring experience short URLSCAN was enabled and has a nice setting enabled (or rather set to disable) by default called “AllowDotInPath”…. The name says it all really and it is meant to block any url that has a dot in the path of the url, I set this to 1 “AllowDotInPath=1″ and saved the INI and suddenly all the WordPress and Magento sites sprang back to life. Thanks for that MS….

So after all that it was such a simple if less than obvious fix.

Anyway I’m writing this to help other admins as I’m sure this is going to effect lots of other people using these sort of php PATHINFO based URL rewriting techniques on IIS.