Friday, 30 January 2015

Windows Azure Pack - Where's my disk space gone?

I was cleaning up an environment the other day and noticed that one of the servers in a Windows Azure Pack deployment was running very low on disk space.

Intrigued as to why I started digging in to find out what was consuming it all and it turned out to be the large amount of etl files (Windows Performance Analyzer Trace Files) that had been created in the C:\ProgramData\Windows Fabric\Fabric\log\Traces folder.

Simple solution, if you're not busy troubleshooting, delete them.

However, why are they created and what can be done to stop them filling the drive again?

One of the parts of the Windows Azure Pack (WAP) that can be deployed is Service Bus.

Kristian Nese has a good post on how to deploy Service Bus here and summarises it quickly as:

"Service Bus provides messaging capabilities that enables you to build, test and run loosely-coupled message driven applications."

One of the pre-requisites for Service Bus is the Windows Fabric application.

"Windows Fabric is a Microsoft technology used for creating highly reliable, distributable, and scalable applications."

You may have come across this pre-requisite before if you've deployed Microsoft Lync Server 2013 which also uses it.

Basically, when Windows Fabric installs it creates some performance counters and logging is enabled on these as default.

You could just stop these, but then if you hit a problem you'll be without the traces to help you.

In the short term, it would be better to enable circular logging instead. This way you will at least have some traces to help (default is rollover at 128Mb).

To enable circular logging, run these commands (Command prompt or PowerShell, it's your choice) on the server with Windows Fabric installed:

Logman update trace FabricLeaseLayerTraces -f bincirc --cnf

Logman update trace FabricTraces -f bincirc --cnf

Oh, don't forget to clean out those stale logs and free back up that disk space!

Tuesday, 27 January 2015

Windows Update missing from the "Classic" Control Panel in Windows 10 TP Build 9926

Rather bravely (or foolishly) I've been using Windows 10 on my main daily laptop since the first Technical Preview was released.

It's had it's up's and down's and just before Build 9926 was released I was hovering over the F12 key to rebuild it back to Windows 8.1.

However I persisted and happily updated to the latest build (9926) and so far, touch wood, it's been much more stable for me, before I was rebooting 4-5 times a day due to crashes and so far I've not rebooted since finishing the installation & patches etc.

However, on that note of patches, I did hit a snag.

See I've still left my device to be managed via System Center 2012 R2 Configuration Manager (yes, I know it's not "supported") and this also means I let ConfigMgr handle the Windows Update side.

This has a slight problem, since ConfigMgr/WSUS isn't aware of this strange OS called Windows 10...

I could go and change my policy in ConfigMgr and exclude my device from receiving managed updates, but that means creating collections, and device settings etc etc.

Normally with previous builds I've just been heading to the Control Panel, Opening Windows Updates and clicking the link to bypass administrator managed updates and check directly online.

But with Build 9926, imaging my horror when I couldn't find Windows Update in the control panel, only it's new modern equivalent, which doesn't allow you to bypass and go direct.

Thankfully, a minor registry edit will bring it back.
Simply add the following value (IsConvergedUpdateStackEnabled & UxOption) to the key paths shown below, or if they already exist change the value to 0 to enable WSUS back in the control panel.



And close and reopen the control panel for Windows Update to reappear!

Cool, now I can bypass ConfigMgr/WSUS and go direct again to check for Updates.