Live Writer is language sensitive

So I though I take a look at Windows Live Writer (since it’s called Essentials it sound as you gotta have some). But vanilla is just not my style I immediately looked at the Live Writer Gallery.

But just to figure that there are no plugins available?! I just couldn’t believe my eyes!!

OK – so switching the language-preference of my browser from german to english helped a lot – seems like Microsoft doesn’t want them germans to get any plugins 🙁

Show 'em all

When you’re working with Sharepoint workspace you might notice that you can create several instances in an meeting-workspace – one for each appointment.

Depending on the template you choose for your workspace, you can upload documents to a document-library in your workspace. These are manage individually for each appointment (aka instance).

Even though it seems as if there would be an individual document library per instance, this isn’t the case. Instead there is only one document library, which is being “filtered” according to the currently visible instance.

To get the content of all instance, all you have to do is to append &InstanceID=ALL to the URL of the list (or document library) and off you go!

When "save" feels like lockdown

So Microsoft really got down to business with this security thing – after installing PowerShell on my new machine I figured, that it’s configured in restricted mode.

This is not some kind of limited mode of operation, but rather this denies the execution of all scripts whatsoever – the term restricted suggested something else, at least in my mindset.

The four PowerShell execution policies include the following:

  • Restricted: No scripts can run.
  • AllSigned: Ps1 and .Ps1xml files must be digitally signed.
  • RemoteSigned: Ps1 and .Ps1xml files from the internet must be digitally signed.
  • Unrestricted: No digital signatures are required and all scripts can be executed.

To find your current policy-setting just use Get-ExecutionPolicy.

Welcome to the credential hell

Getting a brand new system, installed with Vista SP2 and all the latest hotfixes you would assume this is just a top notch system – it’s not!

If you try to access files via WebDAV, for example content on your corporates internal sharepoint server, you’re presented a ton of credential dialogs to enter your username and password just by opening that stupid word or excel file. This is just sucks big time!

For some really strange reason IE thinks that the URL server.companydomain.com is an internet-address and not in intranet-address – event though the domain is set as the intranet-zone in the IE settings. Obviously the WebClient is not recognizing the IE settings in this respect (when it comes to proxy settings, it does honor the IE setting though!).

Well, there are a couple of KB articles describing this problem (like KB 941853 or KB 941890). But they don’t seem to offer any relief.

Finally I came across a blog-posting of the SharePoint Team, which offered some insight of the problem – and finally a solution that worked (at least on my system with installed SP2 – if you don’t have SP1 installed you might need to get a fix from Microsoft):

  1. in the registry go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters and add a new multi-line entry called AuthForwardServerList.
  2. add a white-list of servers/domains to this list to which you would like to automatically pass your credentials. This is the same namingstyle as the zone-settings of IE – so beware of wildcards!
  3. finally restart the WebClient service in order for the new settings to take effect.

Enabling SSO for the VMware Infrastructure Client

Even though you can authenticate to the ESX server using your Active Directory structure, when starting up the client you are prompted to enter username and password. This is just … disturbing.

OK – so just create a copy of the link to the client and change the commandline parameters. Add -passthroughAuth and -s <your servername> to vpxclient.exe and off you go …

Empty Desk-Policy – for Profiles

Every applications nowadays seems to create temp-files without feeling the need to clean up after them-selfs. So I need to take care of this matter.

At least most applications dump the temp-files in the appropriate temp-folder, that is being provided either by the windows environment or via special folders.

OK, but how do you get rid of this junk easily? The answer is simple: just setup an appropriate policy.

In order to do so, you first should create a little script:

cd %temp%
rd . /s /q
cd %windir%\temp
rd . /s /q

Call this script for e.g. del_tmp.cmd and place it in %windir%\system32\GroupPolicy\User\Scripts\Logoff.

Next startup an instance of gpedit.msc and go to user-settings\windows-settings\scripts. Here you can edit which scripts should be run at logon/logoff. Obviously we want our script to run at logoff.

OK, not everything is set to clean-up with every logoff.