I would recommend the use of either Windows Software Update Services (WSUS) or in combination with System Center Configuration Manager (SCCM). WSUS allows you to approve/unapprove all the updates you want to allow in your network. You can group specific computers to a specific set of approved updates if you would like. You can also use SCCM to manage the change control, what was approved, and what was installed. SCCM can also be used to deploy updates in certain circumstances.

Of both of the options, WSUS is free and can be installed on Windows 2k3 or newer. SCCM is now licensed through the System Center package which may or may not be worth looking into if you want to look at the other built in components to it.

I completely agree. I should also mention there have been XP updates in the past (though not like a full service pack) that required you to run before any other update would show up. But alas, nobody probably remember the updates to Windows Update that did this.

The point Microsoft is making here is that 8.1 is going to be supported, but it requires this one update for any future updates. This is probably due to many of the new features and changes to the UI they have implemented. They also probably could have worded it better.

That being said, they need to fix the current issues with their patch first. Namely the TLS issue because if you do not have 2K8 R2 or higher for a WSUS server then you have to turn off SSL because lower versions cannot support TLS 1.2.

Probably not entirely true right now because most of their development has not touched the SDKs for these platforms. It is still a work in progress and their new Unified App framework will most likely make your desire a reality. The fact that they went from Windows CE during the Windows Phone 7.X and earlier days to an NT kernel for 8 shows this progress in the phone space for Microsoft. It also helps that they are migrating from XAP apps to Appx. The new Xbox One uses something based off Windows 8 components (At least kernel, not sure of anything else). Even the Windows for ARM called RT (Big fan of mine by the way for all the haters out there).

They are getting there, but it is not an overnight accomplishment. That would be like saying tomorrow PS3 games will work without recompiling on an Xbox. They have to update headers and references to SDKs they are using to make it work on another platform. This is where Microsoft is really wanting to head with the Unified Apps. They want to have their framework on everything so you do not have to recode. Even better that they are open sourcing good portions of the .NET framework. That would potentially mean that even Android/Linux could use the same app in some ways.

Just saw that. This will be interesting to see. I hope it means only the framework and not 3rd party libraries because that could make licensing or detecting 3rd party libraries interesting. I know I would want my library to still be separate unless I give you the code.

All code ends up at one point or another as native code running against the CPU. There may be several stages before it ends up in native code. Interpreters take the code and convert it into instructions the CPU understands on the fly. The fact that .NET gets converted into CIL means that it should be at least partially interpreted. The JIT compiler is the last step that compiles it into native code for the CPU, but this happens before the code block executes. Now, there are technically ways of using the .NET NGEN tool to pre-compile for the system the code sits on, but until it hits the JIT compiler it might as well be an interpreted language (i.e. C# to CIL). This is why they are just now announcing this native compilation tool where it takes out the CIL step completely. Because .NET currently needs to first be converted into byte code before hitting a compiler, I say that it makes perfect sense that it can be considered interpreted at least to the point of the JIT. If my definition of an interpreted language is wrong then I accept that I am wrong. Most of my beliefs on this stance I would base off of the ECMA-335 specification.

Not true. Native only means that there will be no IL (Intermediate Language) code. Right now .NET is more interpreted than it is compiled. This would mean it gets compiled like C or C++. You would still need the .NET redistributable for any libraries you reference just as you have done with C++ libraries or DLL libraries in traditional Windows development. Not having to compile the code before executing it (using the JIT compiler) means serious performance, but also paves the way to more native support on other devices. Especially since they released it into the open.

I use CrashPlan at home for my 18+TB Home Brew SAN. I have 1 VM running as my file server that has about 10TB of the total storage assigned. I switched from Carbonite to CrashPlan because CrashPlan does not limit bandwidth like Carbonite does (2Mbps for first 200GB and then 200Kbps thereafter). It would have taken me more than 11 years to backup 4TB to Carbonite, but with CrashPlan and my 35Mbps Upload, it took me about 1-2 months for the initial backup of 10TB. Now it only syncs the updated files and has no trouble keeping up. I should also add that you can use CrashPlan to backup to a friend or external hard drive from the same app for Free as well. As for the paid subscription, Business is $7 per PC for unlimited storage and home is like $7 per PC and $14 for a family plan of up to 10. Home edition does not limit installs to non-server systems (as I use mine for personal use). * I am not a paid representative of CrashPlan. Statements are based on personal opinion or experience.

Easier.

Windows 8:
Move mouse to bottom left corner and right click. Pick either command prompt or command prompt in admin mode

Windows 8.1:
Right click start logo. Pick either command prompt or command prompt in admin mode

From that same menu I have quick access to options that took more than a few clicks to get to before. Also in 8.1, you can use this to shutdown or restart.

Personally, I find using the Windows Server Certificate Authority to be great for internal sites. The reason is that it automatically pushes the root cert trust to all domain members. It is also very easy to do a CSR to the internal cert server from IIS. Since you have to still do a CSR no matter how you do your "trusted" cert, going this route can be fairly painless. The other benefit is you can then use your internal cert server for other purposes such as company email signing, encryption, etc... You can also use OpenSSL, but it may take a little more to configure, but it is free. If you have a domain controller, you can just tag on the cert authority too if you are limited on Windows Licensing or hardware.