I just found this great quote (which is actually a quote of another quote – whatever!):
… XML is data dressed up as a hooker …
I just leave it at that.
I just found this great quote (which is actually a quote of another quote – whatever!):
… XML is data dressed up as a hooker …
I just leave it at that.
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 🙁
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!
More astonishing thinks reveal them self, the more I work with my new Vista x64. Apparently PDF preview (using Acrobat Reader) is broken since version 8.x (like 2 years ago!!) and Adobe didn’t bother to fix it since then. All this is nicely documented in an according forum-thread.
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:
To find your current policy-setting just use Get-ExecutionPolicy
.
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):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
and add a new multi-line entry called AuthForwardServerList
.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 …
… if one monitor is just not enough …
Just in case you have an empty spot on your office-wall, check out the new BizTalk Posters. They might take care of that empty space.
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.