If you work with Microsoft Hyper-v on windows Vista or windows Server 2008 then you no doubt use SYSPREP to prepare virtual machine templates. If you are still building each VM and installing windows from scratch then you are making life hard for yourself, in which case I suggest you read THIS.

When you first install Windows your rearm count is set at 3. You can see the current rearm count by running slgmgr.vbs /dlv and looking at the following:

Remaining Windows rearm count: 3

Note: If you install a service pack the count will increase by 1

When you exceed the rearm count you should get error similar to this KB

929828    An error message occurs when you run "Sysprep /generalize" in Windows Vista: "A fatal error occurred while trying to Sysprep the machine"

When you run the sysprep /generalize command, the activation clock will automatically reset, this ensures that when you first boot up you get the 30 day grace period before license activation. This can only be done 3 times, after this you will no longer be able to SYSPREP that windows installation which. This is incredibly annoying as obviously you need to update your templates occasionally. 
However there is a good reason, as if you could indefinitely reset the windows activation then you would never have to activate windows, thus a free license forever. 
NOTE: This limitation does not exist on windows 2003 and XP.

Thankfully you can bypass resetting the activation clock by using the SkipRearm setting in the Microsoft-Windows-Security-Licensing-SLC component. This enables you to run Sysprep multiple times without resetting the activation clock. 
But you MUST remove this setting or set to 0 on the final running of sysprep otherwise the grace period is not reset(additionally the CMID is not reset which can cause problem with KMS activation).

Useful Articles.

• What is sysprep
• How sysprep works
• Sysprep Command Line Syntax
• Unattended Windows Setup Reference

Read more...

I have had this problem a few times where a server with 2 network cards, 1 for local network and one for internet access, will use the local NIC for DNS lookup by default. If your local NIC uses a DNS server which does not perform recursive lookup, then you will have issues making outgoing connections. this may affect all outgoing connections, such as web browsing, or may affect only certain types of connections such as SMTP or applications (such as ColdFusion) trying to make connections to external sites.

In my case I have had this issue with SMTP, more specifically the Microsoft SMTP service that comes with IIS, it simply would not send mail, and I have had this on a few servers.
If you open command prompt and try to do an nslookup of type=mx then it should tell you which name server it is trying to perform the lookup against, and thus why it is failing.

The solution is actually pretty simple, you just need to change the order in which your network cards are used by the system for dns lookups, so that the external nic with the external dns servers is used first.

To do this, simply open your network connection settings "Control Panel\Network and Internet\Network Connections", and press the ALT button to bring up the file menu (this is the bit you probably didn't know about either), then choose advanced –> advanced settings.
Now in the connections list, just move the external nic to the top.

Restart any services which are having issues and bobs your uncle things should be working again.

Here is a video to show you how to change the settings if you are still confused.
http://screencast.com/t/KBJIwrTzX

I recently tried to do some rewrite rules on my ColdFusion site using Helicon APE and could not get them to work for love nor money. It worked fine when rewriting to a non .cfm page, but when rewriting to a .cfm page The result was either a "server error" or a "404.3" error as per the below screenshot

The cause of this is due to the wildcard handler that ColdFusion uses, when you hit a url that gets intercepted by APE due to a rewrite rule which then attempts to rewrite to another CFM page this does not get processed by the wildcard handler, instead APE tries to process the request with a standard script map, the result of which will be different depending on how you have your server setup.

If you have a standard non modified CF install then in addition to the woldcard (*) handler you also have a bunch of regular script map handlers for each extension that ColdFusion handles (*,cfm, *.cfc, *.cfswf etc), these will be named "AboMapperCustom-xxxxxxxx".

Each of these script map handlers points to the file "jrun_iis6.dll" which actually doesn't work at all on IIS 6 or IIS 7 and thus these handlers seem to serve no purpose. Why these handlers are even created I cannot say, my best guess is that they are a leftover legacy setting from IIS 5.
the only handler that is able to process Coldfusion files is the wildcard handler which points to the following connector.

jrun_iis6_wildcard.dll

So in order for APE to be able to work with CFM files or any of the other CF related extensions then you need to update all those script map handlers to point to "jrun_iis6_wildcard.dll" instead of "jrun_iis6.dll".

If you are on a shared host and do not have access to the IIS manager, then you can fix this in your web.config file if you are running on IIS 7, if you are on IIS 6 then you will need to speak with your host as IIS 6 does not have a web.config.

Below is an example of the changes you need to make to your web.config.
If Coldfusion is enabled globally on the server then the <remove> statements disable the original handlers (you must use the original/actual names of the handlers), if Coldfusion is not enabled server wide then you don't need these.

The <add> statements creates a new set of handlers with the correct connector, these can be named anything you like as they are specific to your site. If Coldfusion is already enabled on your site (IIS 7 only) rather than globally then you will already have a bunch of entries like this in your web.config, in which case simply update the "ScriptProcesstor" path as below to point to "jrun_iis6_wildcard.dll" instead of "jrun_iis6.dll".

<?xml version="1.0" encoding="UTF-8"?>


<configuration>


<system.webServer>


<handlers>


<remove name="AboMapperCustom-xxxxxxxx" />


<remove name="AboMapperCustom-xxxxxxxx" />


<remove name="AboMapperCustom-xxxxxxxx" />


<remove name="AboMapperCustom-xxxxxxxx" />


<remove name="AboMapperCustom-xxxxxxxx" />


<add name="AboMapperCustom-xxxxxxxx" path="*.cfm" verb="*" modules="IsapiModule"


scriptProcessor="C:\ColdFusion9\runtime\lib\wsconfig\1\jrun_iis6_wildcard.dll"


resourceType="Unspecified" requireAccess="Script" responseBufferLimit="0" />


<add name="AboMapperCustom-xxxxxxxx" path="*.cfc" verb="*" modules="IsapiModule"


scriptProcessor="C:\ColdFusion9\runtime\lib\wsconfig\1\jrun_iis6_wildcard.dll"


resourceType="Unspecified" requireAccess="Script" responseBufferLimit="0" />


<add name="AboMapperCustom-xxxxxxxx" path="*.cfml" verb="*" modules="IsapiModule"


scriptProcessor="C:\ColdFusion9\runtime\lib\wsconfig\1\jrun_iis6_wildcard.dll"


resourceType="Unspecified" requireAccess="Script" responseBufferLimit="0" />


<add name="AboMapperCustom-xxxxxxxx" path="*.cfr" verb="*" modules="IsapiModule"


scriptProcessor="C:\ColdFusion9\runtime\lib\wsconfig\1\jrun_iis6_wildcard.dll"


resourceType="Unspecified" requireAccess="Script" responseBufferLimit="0" />


<add name="AboMapperCustom-xxxxxxxx" path="*.cfswf" verb="*" modules="IsapiModule"


scriptProcessor="C:\ColdFusion9\runtime\lib\wsconfig\1\jrun_iis6_wildcard.dll"


resourceType="Unspecified" requireAccess="Script" responseBufferLimit="0" />


</handlers>


</system.webServer>


</configuration>

I have recently discovered some issues when running Railo on IIS 7 along with ASP.net and/or custom modules. In certain situations you will get a "Object reference not set to an instance of an object" error on your CFM pages even though they were working fine previously.

In particular my issue was being caused when using custom modules were installed for password protected folder, such as the WebsitePanel module or Helicon APE, which then broke CFM pages.

The solution is actually really simple, you just need to convert your "jakarta" virtual directory into an application. Obviously this only applies if you are using the Tomcat or similar distro which requires such a virtual directory. If you are using the Helicon Zoo module then you will have no such issue.

I am not absolute sure why this occurs, but my guess would be because the request is first handed off of the connector to be processed by Tomcat, which process in the process being returned to IIS with the wrong identity, and thus fails to execute the module in-process.
By setting the jarkarta vDir to an application it then then runs the connector using the application pool identity instead.

So if you switch to a different application pool or identity or even .net version/mode then you may need to also change the jakarta vDir to be the same.

For the last 9 weeks or so I have been on a diet, it wasn't really a choice, my wife discovered DietChef and make the decision for me (I guess she thinks I am too fat), which is probably a good thing as I doubt I would have done it for myself , but I  have to say that I was actually pleasantly surprised, so I decided to write a review.

DietChef is basically calorie controlled dieting for dummies. If you are too too busy, too lazy, too stupid or just lack the motivation and self discipline to control your calorie intake yourself then DietChef is probably just the ticket for you. You get a monthly supply of calorie controlled ready meals (breakfast, lunch and dinner) delivered to your door which you eat every day instead of your usual meals, which you can supplement with things like rice, pasta and vegetables. 
I have always fallen into the too busy/lazy category, I like cooking, but I really cannot be bothered with calculating how many calories in everything I eat, weighing out exact portions, yada yada, this always seems like too much hassle when I get home from work and just takes the pleasure out of cooking...... 

Read more...