The MSS: settings used to be here...

I recently got involved in a project where I defined the Baseline Security settings for windows and Linux. I used the settings provided by the Center for Internet Security (CIS).

We decided on the following approach:

• Based on the CIS templates we created a baseline document specific to our company
• I, in my security role, created a Nessus .audit file, so we could audit compliance to our own baseline with Seccubus
• The windows administrator created GPOs to apply the settings.

When creating in the GPOs we did a strange discovery. In a windows the settings that are normally marked as MSS: in the category Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options do not appear in a domain if its functional level is Windows 2008.

This made us wonder, have these setting become irrelevant ? If this is not the case, how can we still set them, preferably via group policy?

The settings are not irrelevant, as e.g. Peter van Eeckhoutte’s blog points out. Windows 2008 does not forward IPv4 packets that have source routing on them,  but it does accept them if the machine is the final destination. However for IPv6 Windows 2008 will forward these packets by default.

So if the settings are not irrelevant, how can we apply them if they are not in the Group Policy Editor? For this purpose we created an .adm file, which can be loaded into the Group Policy editor as a Classic Administrative template.

All the MSS settings can be controlled with this Administrative template. When we applied these settings we reached our desired compliancy with our own baselines.

Mission Accomplished!

So what are these MSS setting and what do they do?

# 20091218 – vo.o1 – PZO    – Initial hack to delete hardware profiles in Windows Vista/7
#
#————————————————————————————————————————————–
# Let’s see which profiles exist..
#————————————————————————————————————————————–
$i = 0
Write-Host “”
Write-Host “The following hardware profiles have been found on this computer:” -f white
foreach ($profile in (ls -path “HKLM:\SYSTEM\CurrentControlSet\Control\IDConfigDB\Hardware Profiles\”) ) {
Write-Host 000$i – (get-itemproperty -path “HKLM:\SYSTEM\CurrentControlSet\Control\IDConfigDB\Hardware Profiles\000$i”).FriendlyName
$i++
}
#————————————————————————————————————————————–
# Now we can ask which to remove..
#————————————————————————————————————————————–
Write-Host “”
Write-Host “You are strongly advised not to remove profile 0000 – New Hardware Profile” -f red
Write-Host “”
$input = read-host “Which profile is causing you headaches and should be removed?”
Write-Host “deleting.. “HKLM:\SYSTEM\CurrentControlSet\Hardware Profiles\$input”"
Remove-Item -Path “HKLM:\SYSTEM\CurrentControlSet\Hardware Profiles\$input”

Finally: do _not_ remove profile 0000 unless you know what you are doing. YMMV!

[BBG]

Recently we started evaluating Citrix Edgesight, on a enviroment we are currently building, consisting of XenApp5 2008 x64 and XenDesktop 4 Farms.

After the installation of the EdgeSight agent, suddenly a bunch of applications running within a Java Virtual machine stopped functioning. Throwing the “Could not launch the java virtual machine” error.
These Java apps tried allocating quite some memory using these java arguments (eg: XX:MinHeapFreeRatio=20 -XX:MaxHeapFreeRatio=35 -XX:NewRatio=2″   initial-heap-size=”32m” max-heap-size=”1024m”)

After some investigation a colleague (Hugo Trippaers) found out that there was only 0,9 GB of memory allocatable on our Citrix XenApp machines using the memtest32.exe tool. While our other servers happily reported 1,5 GB of allocatable memory (Within WOW64). (Physical Machine = HP DL380G6 with 48 GB of memory, uh should be enough?)

After some deeper digging using memalloc.exe, I discover some substantial differences in memory allocation between our XenApp Servers with the edgesight agent installed and servers without the EdgeSight agent.

XenApp servers with Edgesight Agent 5.2 SP1 x64: memalloc.exe with edgesight
XenApp Servers without edgesight: memalloc.exe – without edgesight

The main difference here is all the Citrix hooks being loaded, see below.
This apparently consumes so much memory that it was not possible for java to allocate enough memory.

For more insights on WOW64 look here:  http://blogs.msdn.com/gauravseth/archive/2006/04/26/583963.aspx

By default 32bit applications within WOW64 can leverage the full 4 GB of memory availlable, which is not possible on a native 32 bit system because of the separation of kernel and user space.
Applications need to be compiled with /largaddressaware (Visual Studio : http://msdn.microsoft.com/en-us/library/wz223b1z(VS.80).aspx) or patched using editbin (http://bilbroblog.com/wow64/hidden-secrets-of-w0w64-ndash-large-address-space/), to fully use the 4 GB availlable otherwise they can only allocate 1,6 GB of memory.

We will open a case with Citrix on this; to be continued.

Citrix hooks being loaded when edgesight is installed:

Address 61200000, length 1000, state 1000 MEM_COMMIT, type 1000000 module e:\program files\EdgeSight\Agent\Agent\Core\rsintcor32.dll
Address 61201000, length 18000, state 1000 MEM_COMMIT, type 1000000 module e:\program files\EdgeSight\Agent\Agent\Core\rsintcor32.dll
Address 61219000, length 9000, state 1000 MEM_COMMIT, type 1000000 module e:\program files\EdgeSight\Agent\Agent\Core\rsintcor32.dll
Address 61222000, length 1000, state 1000 MEM_COMMIT, type 1000000 module e:\program files\EdgeSight\Agent\Agent\Core\rsintcor32.dll
Address 61223000, length 4000, state 1000 MEM_COMMIT, type 1000000 module e:\program files\EdgeSight\Agent\Agent\Core\rsintcor32.dll
Address 61300000, length 1000, state 1000 MEM_COMMIT, type 1000000 module e:\program files\edgesight\agent\agent\edgesight\esint32.dll
Address 61301000, length 8000, state 1000 MEM_COMMIT, type 1000000 module e:\program files\edgesight\agent\agent\edgesight\esint32.dll
Address 61309000, length 3000, state 1000 MEM_COMMIT, type 1000000 module e:\program files\edgesight\agent\agent\edgesight\esint32.dll
Address 6130c000, length 1000, state 1000 MEM_COMMIT, type 1000000 module e:\program files\edgesight\agent\agent\edgesight\esint32.dll
Address 6130d000, length 2000, state 1000 MEM_COMMIT, type 1000000 module e:\program files\edgesight\agent\agent\edgesight\esint32.dll
Address 67f60000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\CtxSbxHook.DLL
Address 67f61000, length 58000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\CtxSbxHook.DLL
Address 67fb9000, length a000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\CtxSbxHook.DLL
Address 67fc3000, length 4000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\CtxSbxHook.DLL
Address 67fc7000, length 7000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\CtxSbxHook.DLL
Address 6db20000, length 1000, state 1000 MEM_COMMIT, type 1000000 module C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_5090ab56bcba71c2\MSVCR90.dll
Address 6db21000, length 96000, state 1000 MEM_COMMIT, type 1000000 module C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_5090ab56bcba71c2\MSVCR90.dll
Address 6dbb7000, length 1000, state 1000 MEM_COMMIT, type 1000000 module C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_5090ab56bcba71c2\MSVCR90.dll
Address 6dbb8000, length 2000, state 1000 MEM_COMMIT, type 1000000 module C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_5090ab56bcba71c2\MSVCR90.dll
Address 6dbba000, length 4000, state 1000 MEM_COMMIT, type 1000000 module C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_5090ab56bcba71c2\MSVCR90.dll
Address 6dbbe000, length 5000, state 1000 MEM_COMMIT, type 1000000 module C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_5090ab56bcba71c2\MSVCR90.dll
Address 751e0000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\twnhook.dll
Address 751e1000, length c6000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\twnhook.dll
Address 752a7000, length 3000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\twnhook.dll
Address 752aa000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\twnhook.dll
Address 752ab000, length e000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\twnhook.dll
Address 752b9000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\twnhook.dll
Address 752ba000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\twnhook.dll
Address 752bb000, length 6000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\twnhook.dll
Address 752c1000, length 5000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\twnhook.dll
Address 75320000, length 1000, state 1000 MEM_COMMIT, type 1000000 module C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4016_none_d0893820442e7fe4\MSVCR80.dll
Address 75321000, length 63000, state 1000 MEM_COMMIT, type 1000000 module C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4016_none_d0893820442e7fe4\MSVCR80.dll
Address 75384000, length 2b000, state 1000 MEM_COMMIT, type 1000000 module C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4016_none_d0893820442e7fe4\MSVCR80.dll
Address 753af000, length 1000, state 1000 MEM_COMMIT, type 1000000 module C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4016_none_d0893820442e7fe4\MSVCR80.dll
Address 753b0000, length 1000, state 1000 MEM_COMMIT, type 1000000 module C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4016_none_d0893820442e7fe4\MSVCR80.dll
Address 753b1000, length 1000, state 1000 MEM_COMMIT, type 1000000 module C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4016_none_d0893820442e7fe4\MSVCR80.dll
Address 753b2000, length 1000, state 1000 MEM_COMMIT, type 1000000 module C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4016_none_d0893820442e7fe4\MSVCR80.dll
Address 753b3000, length 3000, state 1000 MEM_COMMIT, type 1000000 module C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4016_none_d0893820442e7fe4\MSVCR80.dll
Address 753b6000, length 5000, state 1000 MEM_COMMIT, type 1000000 module C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4016_none_d0893820442e7fe4\MSVCR80.dll
Address 753c0000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\scardhook.dll
Address 753c1000, length 1d000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\scardhook.dll
Address 753de000, length 4000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\scardhook.dll
Address 753e2000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\scardhook.dll
Address 753e3000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\scardhook.dll
Address 753e4000, length 3000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\scardhook.dll
Address 753f0000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\wdmaudhook.dll
Address 753f1000, length 2000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\wdmaudhook.dll
Address 753f3000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\wdmaudhook.dll
Address 753f4000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\wdmaudhook.dll
Address 753f5000, length 2000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\wdmaudhook.dll
Address 75400000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\System32\cxinjime.dll
Address 75401000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\System32\cxinjime.dll
Address 75402000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\System32\cxinjime.dll
Address 75403000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\System32\cxinjime.dll
Address 75404000, length 2000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\System32\cxinjime.dll
Address 75420000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\Sfrhook.dll
Address 75421000, length 2000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\Sfrhook.dll
Address 75423000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\Sfrhook.dll
Address 75424000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\Sfrhook.dll
Address 75425000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\Sfrhook.dll
Address 75426000, length 2000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\Sfrhook.dll
Address 75430000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\mmhook.dll
Address 75431000, length f000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\mmhook.dll
Address 75440000, length 2000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\mmhook.dll
Address 75442000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\mmhook.dll
Address 75443000, length 3000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\mmhook.dll
Address 75450000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\mfaphook.dll
Address 75451000, length 2c000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\mfaphook.dll
Address 7547d000, length 9000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\mfaphook.dll
Address 75486000, length 4000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\mfaphook.dll
Address 7548a000, length 4000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\mfaphook.dll

Since the root CA is in another domain then the issuing CA, it took some fiddling and tweaking around with my CDP and AIA extensions, but that is another blogpost all together.

I knew I was in for some fun when when the following happened:

• I installed my Issuing CA and generated the certificate request
• I issued the request to my Root CA and generated the Issuing CA certificate
• I tried to install the Issuing CA certificate and got the following error:

Cannot verify certificate chain. Do you whish to ignore the error and continue? The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2168885613)

My first reaction was to call one of the network guest and notify him that I needed http access to the Issuing CA to the CDP location. But whil on the phone, I decided to try and to my surprise I was actually able to manually pull down the crl.

Intregued, I decided to check a few things:

• I could download the CRL from both CDP locations with Internet Exporer
• I could open the downloaded CRLs
• I could telnet to port 80 of the both webservers
• I could telnet to port 80 manually issue the GET /crl/CRLname.crl HTTP/1.0 command and get data back

O.K. what is going on here… Lets open PKI view, which is now included in Windows 2008 and Vista and can be downloaded for Windows 2000 and 2003.

It seemed that PKI view as in agreement, it too could not download the CRL from the CDP location

PKI view shows "Unable To Download" for both CDP locations

This did sent me on a wild goose chase:

• Microsoft own documentation, clearly blames it on unavailability of the CDP location, something I, by now, had triple checked four times and refused to believe
• This “Network Builders” forum and many others, simply suggest to turn off revocation checking, but that is clearly not a worthy solution either.
• Apparently there is also an issue with serving delta CRLs threw IIS because the + sign at the end of the basename of a delta CRL file leads to so called “double escaping”. I could rule this out by looking at the IIS logs.
• In the end this technet forum post, about OCSP reponders Brian Komar points out:

But, as stated, I would use certutil to get the “best” answer on how is my configuration.
Certutil -verify -urlfetch “certfile.cer” will check *every* CDP and AIA URL (including OCSP) and tell you how they are all doing *at that specific instance in time” since it goes to the URLs immediately.
Brian

I exported the Issuing CA certificate from the certificate database of the Root CA and ran the command against is and this is what I found

E:\>certutil -verify -urlfetch <certfile>.cer
Issuer:
CN=Root CA
Subject:
CN=Issuing CA
Cert Serial Number: 115d5f6400020000000b
<snip>

—————-  Certificate AIA  —————-
Verified “Certificate (0)” Time: 0
[0.0] http://IIS1.domain1local/crl/Root-CA.crt

Verified “Certificate (0)” Time: 0
[1.0] http://IIS2.domain1.local/crl/Root-CA.crt

—————-  Certificate CDP  —————-
Wrong Issuer “Base CRL (13)” Time: 0
[0.0] http://IIS1.domain1.local/crl/Root-CA.crl

Wrong Issuer “Base CRL (13)” Time: 0
[1.0] http://IIS2.domain1.local/crl/Root-CA.crl

<snip>
E:\>

So while PKI view and the other error messages I was getting all pointed to the most common cause, it actually turned out that the CRl did get downloaded, but was not cryptographically relevant to what the system believes is the Root CA certificate.

Root cause

Inspection of the CRLs generated and the Root certificates installed showed what had caused the problem. In order to test the CDP extensions I had reissued the Root CA certificate, causing the Root CA to have three active certificates. Each with a different key.

This CA has three CA certificates

When validating the Issuing CA certificate, validation would end at the last certificate issued, however the CA still signs its CRLs with the key pair of the first certificate.

I guess for me there is nothing left but to reinstall the entire chain.

WAIK 2.0 comes with some new tools like DSIM.exe which is a combination of previous WAIK tools like Pkgmgr.exe, Intlcfg.exe, PEimg.exe and has basic functionality to mount and maintain Windows images (either WIM or VHD file format) by adding or removing device drivers, patches, software packages etc..

Other new features in this toolkit:

• BCDboot is a new tool used to quickly set up a system partition, or to repair the boot environment.
• USMT. User State Migration Tool used for doing an in place migration while maintaining all user data and settings.
• Volume Activation Management Tool. Manages volume activation of Windows clients using a Multiple Activation Key (MAK)
• Hardware recognition and driver injection (also during pre-installation stage while booting from WinPE).
• Create image files for media-based deployments from existing deployment shares (WIM and/or ISO image files).

It supports deployment of Windows XP, Vista, Windows 7, Windows Server 2003/2008/2008 R2

Read more about MDT 2010:
http://technet.microsoft.com/en-us/solutionaccelerators/dd407791.aspx

What’s new in MDT 2010 (link to Word doc):
http://go.microsoft.com/fwlink/?LinkId=163309

Of course there was a warning, as all speakers must have done the last couple of years, about the `ending` of IPV4. We are running out of ip addresses, we’ve heard that before.

Here you will find a nice link of where Geoff Huston is predicting the end of time:http://www.potaroo.net/tools/ipv4/index.html 

And in fact, we cannot ignore this. It will happen. And I want to be prepared, so that’s why I attended this session. I cannot longer sit back and hoping this would only happen when I’m retired. (and the Dutch government is not helping as well, as they have decided to extend pensioning from 65 to 67 years..)

Windows has already implemented the IPV6 stack from 2003 (and XP sp2) onwards and IPV6 from Vista onwards is the preferred protocol by default. Of course you can disable this, but in Win2k8 IPV4 is built on the IPV6 stack, so even when you disable IPV6, you’re always able to ping your local-home-address (::1).

Something I found during my research: Exchange 2003 on Windows 2008 needs IPV6, unless you disable it via a reghack (http://msmvps.com/blogs/ehlo/archive/2008/06/12/1634433.aspx).

You need to understand the principles (doh…) but networking is a piece of cake with IPV6

IPV4 is all about routing, IPV6 is all about shouting, was a statement of Mark Minasi.

Motivators to use IPV6:

• China is knocking at the internet-door.
• All European car-manufacturers have agreed to implement IPV6 in their cars as the standart protocol for car applications. (so beware, breaking will done via commands transported via IPV6..)

I don’t want to get in detail here, plenty of explanation on the web, but the modern OS-es all are capable of doing IPV6, and certainly I will dive deeper into this.  

You should too.

Yesterday we discovered an issue with Windows 2008 clusters: manually added persistent routes disappear from the active routes table, when taking offline (or failing over) a cluster group containing an ip-address-resource.

This issue is documented here. This same article also describes a workaround for when you have multiple gateways on multiple NIS’c.

By changing your route add command from e.g. <route add 10.1.0.0 mask 255.255.255.0 10.1.0.1 –p> to <route add 10.1.0.0 mask 255.255.255.0 0.0.0.0 if 25>

With this second command you bind the route to the interface instead of an ip-address. And since it is now bound to a local device any cluster failover will leave the route in the routing table.

However this will not solve the issue we discovered yesterday: We are using 2 gateways ‘behind’ the same interface. So binding the route to the interface will not help here.

Example interface 18: 192.168.251.36 mask 255.255.255.0 192.168.251.1, with added route 192.168.250.0 mask 255.255.255.0 192.168.251.3 –p.

When an ip-address will be taken offline (fails over) the Active route 192.168.250.0 255.255.255.0 192.168.251.3 will be removed.

Accidentally we found out that adding the interface to the route will solve this new issue (thanks our collegue Enrico). So our new route command will have to look like this:

<Route add 192.168.250.0 mask 255.255.255.0 192.168.251.3 if 18>. This will leave the route in the active routes table.

Why does this work? And is it reliable?

Since we couldn’t find any google/Microsoft hits on this particular issue, we had to do a little registry digging.

The standard command <Route add 192.168.250.0 mask 255.255.255.0 192.168.251.3 > just adds the persistent route to the registry which triggers the ‘bug’.

However the new command <Route add 192.168.250.0 mask 255.255.255.0 192.168.251.3 if 18> also makes 14 changes in the cluster part of the registry telling it that this route is bound to the adapter and to be left behind on the local server in case of a failover

So I think it look pretty reliable. We did lots of reboots and failovers on the cluster and the routes seem pretty persistent now..

Event ID 5156 means that WFP has allowed a connection. When most connections are allowed your security log will fill up very fast.

You can disable Object Access auditing but then you’ll miss other events which might be of interest. So, instead, let’s just disable Success Auditing for Filtering Platform Connections. It’s not possible to disable auditing subcategories with a policy or other GUI tool, but I found out that you can enable and disable specific subcategories with a special command-line tool: Auditpol.exe, which is included with Windows Vista and Windows Server 2008. I used the following command:

auditpol /set /subcategory:”Filtering Platform Connection” /success:disable /failure:enable

As you can see this disables Success auditing for the Filtering Platform Connection subcategory.

For more info check out this article:

http://msdn.microsoft.com/en-us/library/bb309058(VS.85).aspx

• 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

4 days earlier then I had in my previous schedule, Microsoft has now set July 13th for RTM “sign-off”

Sign off is the process where all divisions sign that they agree on the final code, which means the actual RTM build will be created a few days earlier, which is targeted on July 10th.

The general availability (GA) is set to October 22nd, this is when you can buy it in stores in a box or on new PC’s (OEM).

We can expect the RTM much earlier on MSDN, Technet and Volume Licensing download sites, probably a few days after July 13th.