Word to the wise. Azure does not ship with any fonts.
If install any fonts onto Azure make sure you have the proper licensing. You can be paying big money out to Microsoft or Monotype if they learn you put Arial or some sort of other IP on a server without a license.
The fonts that sit on your local machine in your fonts folder are to remain there. By moving these fonts onto a server, shipping them in software you violate the EULA and can be sued if they find out.
I recommend doing this with legit open source fonts, not with the MS fonts in your font folder.
That's a very good tip. But I have to disagree in one point, there are fonts delivered with the instances you fire-up in Azure. The standard system fonts like Arial are installed and you license the Worker-Role. You pay for it. You can use those fonts (and those are not in the range of this article). Usually you have to pay for the system fonts if you want re-distribute them. Here is a sample link:
Thanks so much for posting this, I wanted to share my experiences with this article.
Long story short, I found that running FontReg directly using elevated permissions works just fine - without the need to use PSExec under an Admin user.
In fact, I couldn't actually get FontReg to run through PSExec as a startup task. I could run the batch file directly on the machine, but as a startup task the fonts just wouldn't install even though the script was running successfully. Both the role, and the startup task were running elevated.
Secondly, the %ROLEROOT% environment variable seems to be nonexistent on our VM's (we are currently using OS 3.8) - I checked both our Web roles and Worker roles and the variable just isn't there.
So given these points, this is the batch file we ended up with:
<a href="/Members/echo">@echo</a> off
cd "fonts"
echo running fontreg ... >> test.txt
start /w fontreg.exe /copy
exit /b 0
As you can see we're using a relative path from the batch file. At one stage we had hardcoded the drive letter - DO NOT DO THIS! As when you do an upgrade, the letter changes (we learnt that the hard way, it brings down the entire role).
Finally, we found that only the startup task needs to run elevated - the role itself does not. This means you DON'T need the following in your csdef:
thank you for sharing your thoughts and experiences I will update my article according to what you have found out. People on Twitter have made similar experiences and had other issues like using a different versions of psexec that (according to them) don't work as expected.
I am surprised to hear, that %ROLEROOT% does not exist on your machines. Here is the current (or latest) Windows Azure Guest OS Releases and SDK Compatibility Matrix :