Every now and then Microsoft Outlook decides to show its reminders in a strangely deformed reminder window.
Sorry what do I need to remember?
As allways Google was my friend and pointed me to this post.
The key is the value WindowPos in this registry key: HKCU\Software\Microsoft\Office\12.0\Outlook\Options\Reminders
If you delete this key from the registry and restart Outlook the reminders window is back to its normal size.
Another tip from Elianne van de Kamp, which I of course couldn’t keep to myself. Your Windows 2008 KMS key (replacement of the Volume License Key/VLK) can be registered for a maximum of ten times on six different machines. If you want to extend this you will have to file a request at your Microsoft representative with lots of information:
- Organization name
- Agreement number
- Authorization number
- Requester name, telephone, etc
- Product
- Last 5 digits of your KMS key
- Number of additional activations
- And last but not least: A good reason why you need extra activations.
The process takes 48 hours to complete, which means you have to wait that long before your extra activations are available. The first step to activate your KMS key is to register it with:
slmgr -ipk xxxxx-xxxxx-xxxxx-xxxxx-xxxxx
It will tell you the key is valid (or not, but you then have another problem). Then you have to activate it with:
slmgr –ato
When the key is out of activations it will respond with “ERROR: 0xc004c008: the key is valid, but cannot be activated.”
Instead of filing a 2 day taking request you can use a quick workaround:
- Enter the KMS key as the registration key on the KMS server. (Control Panel – System – Change product key).
- Activate the key. You will get a message the key cannot be registered. Choose activation by phone.
- Call MS activation line. Enter the numbers into the automated response, and you will receive the 8 times 5 new key.
- Enter the numbers and you’re all done, the KMS server will now be activated.
You can check this with:
slmgr –dlv
Full credit for this goes to Elianne van de Kamp, who’s been busy with the investigation for quite a while. What happened?
On the 9th of September, together with the regular MS updates an update for WSUS 3.0 came in: Service pack 2. The first issue we encountered was the fact it was announced as an upgrade. It performs a re-install though. This means you have to reconfigure the basic setup of WSUS. The computer list and grouping definitions are safe in the database. Things like which updates and which language to download will have to be configured again though. Being prepared here by making a note of current settings will help.
We ran into a new issue the next morning. The upgrade of WSUS also upgrades all clients with the Windows Update Agent. This runs flawless on 32 bit windows clients. It causes an issue on 64 bit windows however: two files, NT5IIS.CAT and IASNT4.CAT are replaced, probably by 32 bit versions. When you connect to the console of the server it will tell you about this in the form of a Windows File Protection Error. The choice is yours to cancel this warning and ignore like we did, because it concerns a database server and the files will never be used (NT5IIS for web server, IASNT4 for internet authentication). You could also cancel and replace the files manually from CD or service pack. Fact is that the files copied with this update are dated 25-05-2005, so very old and will most like cause problems when you ever need them.
I thought I’d share this information as I’m sure other people will run into this problem as well. Would be a shame if they had to go through the same cycle!
Overview of Microsoft patches due today by Microsoft
Microsoft is even more vague than usual about the patches it plans to release today.
In this patch announcement Microsoft only states that it plans to release 5 patches.
This is the data currently known:
Read more…
Today Microsoft released two out of band patches. Remarkably one of the patches is a moderate patch in itself however, it turns out that this patch is for a flaw in Microsoft Active Template Library (ATL). If software is built using this ATL it contains a vulnerability which can be exploited easily and can lead to arbitrary code execution on a client e.g. when surfing to a malicious website. Interestingly the active content (ActiveX control) is executed even when a killbit for the ActiveX control has been set. A preview demonstration is available online and details will be disclosed on the BlackHat conference tomorrow 29-7-2009 3:25 PM (GMT-8).
Read more…
Interesting insights on the new Windows 7 UAC… (http://www.pretentiousname.com/misc/win7_uac_whitelist2.html)
Win 7 UAC Code-Injection: Summary
On 5th February 2009 I wrote a proof-of-concept program to demonstrate a security flaw in Windows 7′s UAC, under default settings with beta build 7000 (also confirmed on 7022). This simply copied a file to Program Files without the user’s consent. In other words, it performed a file copy to a protected location, bypassing UAC.
“So what? All it does is copy a file?”
On 9th February 2009, to show the implications of being able to copy to System32 and Program Files, I created a second proof-of-concept program which uses the original exploit to open up a hole which in turn allows it to run any command or program with full elevation without itself requiring elevation or the user’s consent.
All of this is done without using the SendKeys or RunDll32 holes which were found earlier in February. It is done using a method which can attack almost any Windows executable and which is inherent to the changes Microsoft have made to UAC in Windows 7.
The proof-of-concept works on unmodified installs of Windows 7 beta build 7000 (and confirmed on 7022), both 32-bit and 64-bit versions, at default settings.
Setting UAC to its highest level, or using a non-admin account, will prevent the proof-of-concept from working by forcing it to display a UAC prompt. However, neither of those are defaults in the current Windows 7 betas.
As well as discussing the proof-of-concept code I argue that:
- Microsoft should either admit that local process elevation is a problem and make Windows 7 more secure by default or admit that the Windows 7 default UAC settings are security theater (as they offer no protection) and anti-competitive (as they are inflicted on third-party code despite local elevation supposedly being a non-issue).
- If there is to be a UAC whitelist, or the equivalent of one, then it should be up to the user which Microsoft and third-party software is on it. Users should not be forced to expose themselves to risks from software they do not use. Conversely, if reducing UAC prompts in frequently-used software is needed to stop people disabling UAC entirely then that applies to third-party software as much as to bundled software (especially once a machine is past the “setup” phase).
- UAC itself was a good API and a good design that was given a bad name because of the way it was used by Microsoft’s application-level code (such as Explorer and Control Panel). Accordingly, the user experience of having UAC enabled could have been vastly improved by changing the application-level code without opening a huge hole in UAC.
- Microsoft created these problems themselves and, rather than fixing them properly, have taken the easy way out, unnecessarily making UAC less secure in the process. At the same time Microsoft expect third-party vendors to do a better job than they bothered to do using the API which they themselves designed.
If you’re already shouting, “But it’s only a beta!” then there’s a section for you, too. 
And, for the record, I like Windows and much of what Microsoft do, in general. I even like UAC (the API, not the way it has been used). I wrote this page because I care about the platform not because I get a kick out of attacking something Microsoft have done. I call things as I see them. I attack and criticise some of what Microsoft do and I support and defend Microsoft other things that they do.
From: http://www.pretentiousname.com/misc/win7_uac_whitelist2.html
List of binaries which are allowed “auto-elevation” :
http://www.withinwindows.com/2009/02/05/list-of-windows-7-beta-build-7000-auto-elevated-binaries/
I got this error (PKCS#11 smart card self-service control error: Invalid Signature.) while enrolling a certificate onto my Smartcard using Microsft CLM 2007 FP1.
Looks like Microsoft Certificate Lifecycle Manager FP1 is not yet compatible with Windows 7 RC1. No issue however with Vista SP2.
Only enrolling seems to be an issue, all other functionality just seems to work… if I find I solution to this then i will post it here… If you’ve got an solution? please leave a comment!
Windows XP Mode on Windows 7 could be used as workaround as well (The smart card is accessible from XP Mode!). But the following requirements must be met for this to work;
- Virtual XP Machine needs to be a domain member
- Have the CLM Client tools installed
- Have the SmartCard middleware installed.
Finding the next available driveletter on a system, excluding reserved driveletters, can be done using the following PowerShell 1-liner.
[char[]]”DEFGJKLMNOPQRTUVWXY” | ?{!(gdr $_ -ea ‘SilentlyContinue’)} | select -f 1
The character array containing only valid driveletters (in this example A, B, C, H, I, S and Z are not to be used) is piped to the where-object cmdlet which uses Get-PSDrive to filter out the non-used drive letters. These are then passed to the Select-Object cmdlet which only displays the 1st match.
Beware: the line above returns only the bare driveletter – no colon is appended.
The full version of Windows 7 Home Premium is priced at $199, with an upgrade from Vista or XP costing $119. The full version of Windows 7 Professional is $299, with upgrades going for $199. Windows 7 Ultimate is priced at $319, with the upgrade version at $219. In what’s perhaps a nod to the recession and increased competition in the software market, the prices are about 10% less than what Microsoft charged for the corresponding versions of Windows Vista when that product shipped in January of 2007.
More here: http://www.informationweek.com/news/windows/operatingsystems/showArticle.jhtml?articleID=218101310&subSection=All+Stories
Comparing version numbers can be tricky from time to time, before you know it you end up in auto-casting issues comparing strings to integers etc. The most common format of a version number in Windows is “Major. Minor. Build. Revision” where each individual item is a figure, but because of the separating dots PowerShell will treat each item as a string.
The .Net System.Version assembly offers a CompareTo method which can do the trick, as shown in the figure below.
The CompareTo method will return 1, 0 or -1 depending whether the compare to version is higher, equal or lower.
Thanks to Shay Levi (see the comment) I now know a better/faster method for comparing version numbers (thaks Shay). PowerShell has its own [vesion] type. This removes the need of loading the assembly and using New-Object. It still allows for using the CompareTo method and direct compare via -ge, -gt, etc.
The CompareTo method will distinguish between the 3 possibilities (>, < or =), but direct comparison might be sufficient in a script.
