Running a Powershell script as a scheduled task

It should have been simple. I have a Powershell script that works as it should, I just need it to run on the hour, every hour. So create a scheduled task, and attach the script. Do a run now, just to make sure it works.

And technically, it works. That’s what the result of the scheduled task says: Task Completed 0x0. But the actual Powershell script hasn’t been actioned.

Once again I confirmed that running the script by itself works. I wrap the code in the script in a Try/Catch with a log file. But nothing writes to the log file.

I googled and googled, and checked all the following things:

  • I globally set Set-ExecutionPolicy to Unrestricted.
  • I tried running the task under a local account with admin permissions, as someone mentioned that domain accounts can’t run scheduled tasks. That doesn’t appear to be the case.
  • I checked that my account has Log on as batch.
  • I added the run script command to a batch file, and called the batch file from scheduled tasks. Still didn’t work!

It turns out that even when setting the Set-ExecutionPolicy to Unrestricted, you still need to add the parameter -ExecutionPolicy ByPass. Just that one little thing. If you are asking an application to run a script for you, it needs to bypass execution policy.

So the correct config was:

Program/script: “Powershell” (should resolve correctly to powershell.exe)

Arguments: -ExecutionPolicy ByPass -File {script file with path}

Start in: {Path of folder that script sits in}


2008 SSRS Report from CRM 2011: Font with space in its name not rendering correctly

Google was truly not my friend for this one, so now I’ve hacked fixed it, I’m giving back in case anyone has the same issue.

I’ve been tasked with creating some pretty reports in SSRS 2008, which will run from CRM 2011. The company font I’ve been asked to use is Century Gothic.

I created the reports, which rendering perfectly in preview mode and when creating PDFs in SSRS. I then uploaded the reports to CRM, and ran it from its entity.

All instances of Century Gothic came out as Times New Roman. The same happened when exporting it to PDF. Century Gothic didn’t appear to be installed on the CRM report server, so I installed it on there and scheduled the server reboot overnight.

The next day, it was still Times New Roman, except for one textbox which had Century Gothic displayed correctly.

Looking under the hood with developer tools, I saw this:


I cracked open the code, but I couldn’t see any difference between the working correctly textbox, and the others, which had the split font name. I tried putting quotes, singe and double, round the font name in the code, but Visual Studio then couldn’t resolve the font name correctly itself.

I tried other fonts with two names, and got the same problem.

Looking at the working textbox, I saw that the textbox itself didn’t have a font set, only the selected text inside:

ssrs-crm-font-2 ssrs-crm-font-3

The broken textboxes had the font applied directly to it. Creating a new blank textbox automatically assigns a font to the box, which can’t be cleared.

So how to fix it? The working textbox had a bit of Arial text in it as well. So that gave me the idea to add a couple of spaces to the end of each Century Gothic textbox, and make one of those spaces Arial.

That cleared the Font property on the textbox, and then the Century Gothic font started displaying.

What a horrible, hacky fix 😦

Server 2003 needs hotfixes for SHA2 256 or higher encryption, or X.509 certificates

Are you still running Windows Server 2003? For shame!

Have you been keeping up with the hotfixes? Hmmm…

Well, you’re in good company. Forgetting for a moment that Microsoft ends support for Server 2003 on 16 July 2015, sometimes it’s easier to just let it keep running.

Beware what happened to us though. Our website stopped serving up a page in an iFrame from a secure site. We spoke to the company, who said the certificate had been updated and to just grab the new one. I had no problem on my local machine going directly to the page, but couldn’t do it via the website.

The company had updated their certificate to a version which our Server 2003 could no longer communicate with:

Windows Server 2003 and Windows XP clients cannot obtain certificates from a Windows Server 2008-based certification authority (CA) if the CA is configured to use SHA2 256 or higher encryption

Applications that use the Cryptography API cannot validate an X.509 certificate in Windows Server 2003

Not to mention that the server had IE6 on there. But thanks to Hotfixes and a swift restart, our 2003 Server machine lives to fight another day, until we finally put it out of its misery. Soon I hope.