Paul H's questions

When we make a delivery to our LIVE webservers we like to test they are working. As we have several load balanced webservers in LIVE we need to browse to each one individually. These are Windows Server 2008 webservers. To check the websites are OK on each webserver we currently browse to the website locally through IIS.

This process is painfully slow.

Is there a way to speed up this process?

Note: If we try to browse the webservers externally we end up on one webserver - and then seem to always hit that same webserver afterwards: which means the others go unchecked.

We have a number of Windows Scheduled tasks that run on one Server 2008 Webserver (not R2) which is in a cluster.

We recently moved from an original webserver Cluster to a new webserver Cluser (Server 2008 - not R2).

The new webserver (in the cluster) running the Windows Tasks is setup the same as on the original we believe.

BUT we now find that on the new Windows Server the Windows Task Scheduler seems to want to instantly start each task three times.

If we set the option to queue up a new task we get:

Event ID 324 Task Scheduler queued instance "{9a1a8411-b042-45ff-8e6b-89874df230d7}" of task "\Client Reporting" and will launch it as soon as instance "{2bcc3df6-ea3b-4453-90c2-75b8b1946388}" completes.

If we set the option to stop an existing task we get:

Event ID 323 Task Scheduler stopped instance "{e685a910-b32b-414e-85fd-96bbe54314a2}" of task "\Client Reporting" in order to launch new instance "{4db66265-1f51-4ede-8535-ac7c3cb5c4c1}" .

Ticked settings:

• Allow task to be run on demand.

• Run task as soon as possible after a scheduled start is missed.

• Stop the task if running for longer than 1 hour.

• If the running task does not end when requested force it to stop.

• Start the task only if the computer is on AC power.

• Stop the task if the computer switches to battery power.

Selected option: If the task is already running - stop the existing instance.

Note: We moved the tasks from one server to another in the cluster to see if it the Task Scheduler on the particular server we'd picked causing the problem. Same behaviour.

Could it be something to do with the build of the new servers?

We have very similar tasks set up on another server cluster that work OK without all this multiple starting. Comparing those tasks to the ones here - there does not seem to be anything obviously different in terms of settings available to us through the options within the Task Scheduler.

Trigger: The task is scheduled to be triggered daily, once an hour - and to be stopped if it exceeds this time.

Action: Runs a .bat file.

What could be causing this/where we can look to see what logic is causing the tasks to start multiple times in this way?

Is there a way in IIS of detecting a user is browsing via a mobile device [maybe by checking their User Agent against a list?] so they can be redirected to a mobile-specific website? Or would this logic have to occur at the application level? Note: All websites involved are HTTPS.

It's IIS 7 running on Windows Sever 2008 R2

I want to startup iexplore once an hour pointed at a specific url to kick off some processing. It's a Windows 2003 server with Internet Explorer 7 running in enhanced security configuration.

The scheduled task is set to not require the user to be logged in to kick this task off.

When I am logged in I can see the iexplore window popup and disappear again and I know it has accessed my url (I've set it so I get an email).

When I am not logged in I do not get anything triggered from my url - but when I look at the Scheduled Log it says the task ran the program OK with an exit code of 0. I can only therefore assume that iexplore pops up - but does not go to the required url.

Is this something to do with IE's 'enhanced security configuration'?

What do I need to do to get it to open IE and actually go to my url?

Clarification: The url points to a .aspx page - so I'd want something that can start up a web page and not fall over when the .aspx page tries to access sesson info.