Author: Adam Fowler

Windows 8.1 Uptake Will Be Slow for Enterprise

Opinion: Windows 8.1 was officially released on the 18th October 2013. Many people had their hands on it a few weeks earlier, due to Microsoft releasing the RTM version to Technet and MSDN subscribers. People have been waiting for this release, especially with the mixed press around Windows 8. Windows 8.1 seems to address a lot (but not all) of the general complaints out there in consumer land, but for Enterprise it’s a different story.

Windows 8.1 fixes several key complaints – The start button is back to try and lessen the blow in changing how stuff works for users, the Windows App Store now supports a proxy using NTLM Authentication (yes, TMG/ISA!) and many other benefits.

The big show stopper is going to be Internet Explorer. This is one of the main reasons XP has lasted so long in the Enterprise space, when so many companies were stuck with IE6 and couldn’t jump to Vista (OK, nobody really wanted to for other reasons too) as Vista came with IE7 and couldn’t be downgraded. Windows 7 had the same issue, out of the box you get IE8. All it takes is one key Enterprise application that doesn’t support anything above IE6, and you’re stuck on XP until that issue goes away. Now maybe the application works on something newer, but if you run into any issues your huge support dollars are useless, as you’re now running it in an unsupported way.

IE6 finally started to die off and everyone’s now been jumping to Windows 7. The Windows 7 jump forced IE8 onto everyone, and most Enterprise applications touted IE8 as the new standard browser they supported. All was well for a while, and in the meantime IE9 and IE10 were released.

Software developers have been getting better at this overall, and usually IE10 will now be a supported browser. IE10 had been coming since April 2011 and was released September/October 2012 for Windows Server 2012/Windows 8 respectively, and then Windows 7 February 2013. That’s a long window for software developers to start getting on board and supporting it.

Often for support, a product upgrade is required. This can set back a company a reasonable amount, depending how complicated, costly and time consuming the upgrade is – and how other projects are affected.

Windows 8 was brand new when IE10 came out, but Enterprise generally held off due to the major UI change for users, waiting for Windows 8.1 to fix it.

Jump forward to June 2013, and IE11 is first released as a developer preview. Only 3 months from that, and it’s now bundled in with Windows 8.1 and Windows Server 2012 R2. This is an incredibly small window in comparison to IE10, so hardly any developer will support this for quite some time (many are still catching up to IE10).

So where does this leave the SOE for an Enterprise? Stuck on Windows 7. They don’t want to jump to Windows 8 because 8.1 fixes so much, but they can’t jump to 8.1 either because hardly any Enterprise applications will support the default IE11.

Why not just use another browser? Firstly, you need to use one that all the software developers support, and then you’ll run into similar issues around version support and control. Just because Google Chrome does lots of little updates doesn’t make it more stable, you don’t know which next update could potentially break a function, and again you’re stuck with no support by running a version higher than what’s officially recognised.

Why not just use a different software developer? Enterprise applications are often aimed at particular industries, and often there’s a single leader. That generally means you have to start losing functionality, spend huge dollars and time to move away from the product you’ve used, get all your staff retrained and so on. From someone up top, this just seems like a waste of money if you’ve got something that works now.

So, what’s the real solution here? Hopefully competition will play a factor where more versatile software developers can make great products and beat the slower moving ones, but that often takes a long time to occur (the speed of a glacier comes to mind). Solutions like Citrix XenApp or Microsoft App-V for deploying a sandboxed browser to run the app virtually/hosted is a decent workaround, but adds extra complexity.

I think out of necessity, existing software developers will start to adapt faster. Microsoft’s model is moving towards yearly updates for all their products, and that will keep getting shorter and quicker to keep up with the newer players to the industry. Customers will start making this sort of support as high up on the list of demands, rather than asking and accepting what they’re given.

Windows 7 will still be seen as the new XP for a while, but we shouldn’t see such a huge % of Windows 7 PCs out there when it’s life span comes to an end (2020 if you were wondering).

It is still a long way off, but compared to where we are now versus several years ago, we’re doing a lot better. Windows 8.1 will get there, but not until all the legacy apps support IE11.

Update 04/11/2013 – Interesting writeup from Michael Stum, from his website ‘Not Rocket Science’ called “Google Chrome is not usable in a corporate Windows environment” http://stum.de/2013/11/01/chrome-is-not-usable-in-corporate-windows/ – thanks @nickstugr for the link!

More LinkedIn Security Risks with LinkedIn Intro

LinkedIn have just announced a new way they’ve engineered LinkedIn user information into the native iOS mail reader. Have a look at the article here: http://engineering.linkedin.com/mobile/linkedin-intro-doing-impossible-ios#!

In principal, this is an interesting idea – it’s what CMS (Customer Management Systems) have been doing for a long time, which is integrating a database of users/companies into your emails so at a glance you go from email address to user profile to company all in the one spot.

From a user perspective, this is quite neat. Seeing where someone works as part of the email, their job title, other connections saves a lot of time and brain energy when they’re thinking ‘who is this guy?’ – but from a security standpoint this is bad.

LinkedIn’s whole quote on the privacy aspect of this is:

Security and Privacy

We understand that operating an email proxy server carries great responsibility. We respect the fact that your email may contain very personal or sensitive information, and we will do everything we can to make sure that it is safe. Our principles and key security measures are detailed in our pledge of privacy.


That doesn’t say much, apart from ‘Come on.. trust me!’. Firstly, you’ve got to give LinkedIn your email password. Check my previous article as to why this is bad: http://www.adamfowlerit.com/2013/06/02/linkedin-securityinformation-risks-with-exchange/ – a pledge of privacy isn’t going to help you after a catastrophic event.

So, this method is actually worse again. All your emails traverse via LinkedIn’s proxy service, the email gets modified then delivered to your iOS device. Emails are insecure by nature as they traverse the internet in plain text format (excluding things like PGP and other encryption methods that most people/companies don’t use), but having them centrally filtered via a 3rd party means you’re giving them a truckload of information about yourself, who you deal with, your email habits and so on.

Would your company be happy with a 3rd party that you have no agreement with, receiving and forwarding on all your emails? Even if the emails aren’t stored, if LinkedIn was breached again (which they have been before, multiple times), other people could obtain anything from your contacts, to your password and email contents.

oAuth is supported too, which is a safer approach as it can be revoked – but you’re still giving the same level of access while the connection is approved.

Luckily for Exchange administrators, that doesn’t seem to be supported yet according to https://intro.linkedin.com/micro/faq but for Google Apps people, you’ll need to look into how this can be blocked if you want to. If you’ve found out how, I’d be happy to add it to this post.

Update: There is a great writeup from Bishop Fox on several great reasons as to why this is a ‘bad idea’ http://www.bishopfox.com/blog/2013/10/linkedin-intro/

SCCM 2012 R2 Upgrade Breaks Report Builder

Hi,

Just a quickie. After upgrading System Center Configuration Manager 2012 SP1 to R2, I could no longer create a report in the console. The error you see when clicking ‘Create Report’ is “The Report Builder click-once application does not exist on the report server ‘blah.server.com’. Ensure that the report builder application manifest exists on the server and try again.”

It DOES exist, just that the R2 upgrade changes a few settings.

This is actually the same issue when SP1 is installed, with the exact same fix. The full details are on this technet article: http://blogs.technet.com/b/smartinez/archive/2012/07/03/system-center-2012-configuration-manager-create-report-don-t-work-what-do-i-do-now.aspx but the brief two steps to perform on your SCCM/Config Manager server are –

1. Change the registry key “HKEY_LOCAL_MACHINE/SOFTWARE/Wow6432Node/Microsoft/ConfigMgr10/
AdminUI/Reporting/ReportBuilderApplicationManifestName” from the value “ReportBuilder_2_0_0_0.application” to “ReportBuilder_3_0_0_0.application”

2. Edit the file
“C:\Program Files (x86)\Microsoft Configuration
Manager\AdminConsole\bin\Microsoft.ConfigurationManagement.exe.config” and change the 2 to a 3 in the two areas:

 

Before
<add key=”10.0″ value=”ReportBuilder_2_0_0_0.application”/>
<add key=”DEFAULT” value=”ReportBuilder_2_0_0_0.application”/>

After
<add key=”10.0″ value=”ReportBuilder_3_0_0_0.application”/>
<add key=”DEFAULT” value=”ReportBuilder_3_0_0_0.application”/>

 

That’s it. You should now be able to build reports again.

Microsoft Remote Desktop for iOS

Hi,

Today, Microsoft released “Microsoft Remote Desktop” for iOS devices (iOS 5+). For a long time, the Apple store has contained many 3rd party solutions to this which usually require a 3rd party app to be installed on the Windows PC you’re connecting to (never a fan of this option), or have ‘basic’ Remote Desktop support, without the Network Level Authentication. This app supports it.

Firstly, by allowing this on any PC you’re opening up a way for attackers to get in. You need to weigh up the risks with this, and what data can be accessed. I won’t get into that with this post, but consider firewall settings and potentially using a VPN for extra security.

The iOS side of things is very simple. Go to the app store, install the “Microsoft Remote Desktop” app and launch it. You’ll end up with a ‘RD Client’ App on your home screen, and when launched will look like this (without my ‘Home’ connection):

2013-10-18T14-47-25_0Pretty clean. So, you can add a ‘New Remote Desktop’ if you know the PC name/IP address you’re connecting to. Most people will want this when they’re out and about though – so the first thing to do is make sure Remote Desktop is enabled on your PC.

At the PC end under System > Advanced System Settings are the Remote Desktop settings. Make sure you’ve got the ‘Allow connections only from computers running…’ tickbox selected. Why? Have a read here http://technet.microsoft.com/en-us/magazine/hh750380.aspx but the summary is that it’s more secure and is less susceptible to attacks.

system propeties

For the ‘Select Users’ box, add only the accounts you need to use remotely (unless they’re already a local admin). As part of this, you should have your local administrator account disabled as that’s often what someone or something will use as a username to try to access your PC. The account you’re planning to use can be a Microsoft account, so you’d just enter your email address (e.g. [email protected]) with your password, and that will authorise you to the PC.

Keep in mind you may need to allow port 3389 (RDP) traffic in via your Router, and have that go to the PC you’re trying to connect to.

Once you’re on, the iOS app is rather clean and easy to use. You’ll see a small menu bar at the top of the screen. To the right is the keyboard which has all the keys I could imagine wanting (even a start button!), and to the left is a zoom/scroll button. Pressing this shows a small circle in the top middle half of the screen, and zooms the screen in. If you want to navigate around in zoomed mode, press the circle and swipe the way you want to go. If you just swipe without starting at the circle, you’ll probably end up highlighting text like a mouse would. Right clicking is done by holding down your finger, and you’ll see a small square appear and increase in size, until the right click happens.

You can also change to mouse mode by pressing the middle of the top menu, which will drop down a larger menu. On the left side you’ll see a hand, press that and it will change to a cursor. The right side of this menu has the disconnect option when you’re done.

Android and Windows Phone 8 versions of Remote Desktop are on their way too, with the Android version available here: https://play.google.com/store/apps/details?id=com.microsoft.rdc.android

Also Simon Sharwood from The Register has posted this article about the app and quoted me :) http://www.theregister.co.uk/2013/10/18/windows_comes_to_android_ios/

Finally, here’s a really good article from Berkley University around Remote Desktop security https://security.berkeley.edu/node/94?destination=node/94

Troubleshooting NIC Drivers in WinPE for SCCM 2012

Hi,

This is one of the problems that every SCCM (System Center Configuration Manager) admin will come across. You’re trying to deploy an image to a PC from PXE booting, and you can’t get the list of task sequences to show up. The PC will reboot, and you’ll wonder what happened.

There’s several different ways to troubleshoot this, but it’s most likely network card drivers required in your Boot Image in SCCM. Where do you start on this though? There’s a couple of things to enable/set to make it a little easier.

First, enable command support on both your x86 and x64 boot images (Software Library > Overview > Operating Systems > Boot Images). This will allow you to press F8 when running WinPE from a task sequence, which brings up a command prompt to let you check things like log files.

The other setting I recommend is making custom Windows PE backgrounds (same screen as the command support option). Have one for your 32 bit Boot Image, and a different one for your 64 bit. This means when something fails, you can tell at a glance which boot image was used and troubleshooting accordingly.

boot image

Back to working out your NIC issue. If the task sequence is bombing out early on, press F8 to get your command prompt, then use the command ‘ipconfig’ If you see hardly any information, including the lack of an IP address then it’s a strong indicator that the correct NIC driver isn’t loaded. I’m going to guess you’ve checked the network cable is plugged in :)

To work out what NIC driver is required can be tricky. If your hardware came with an OS already loaded, or a recovery disk, you can load that up and from Windows see what driver is associated with the Network card. Here’s a good step by step guide on how to add the drivers: http://gerryhampsoncm.blogspot.com.au/2013/02/sccm-2012-sp1-step-by-step-guide-part-9.html

Generally (but not always) the driver you see in the standard OS should work in the WinPE environment too. You will probably need both 32 and 64 bit versions injected into the relevant boot images.

There’s also the log files to read, which can be rather messy when you first start out. From the command line window, run the command ‘cmtrace x:\windows\temp\smstslog\smsts.log’ and have a read – that’s your best bet to find out what’s causing your task sequence to fail. Do a quick google of the error code number you see to get an idea on what you’re dealing with.

Here’s an incredibly long breakdown of SCCM 2012 log files if you’re that way inclined: http://technet.microsoft.com/en-us/library/hh427342.aspx

Sometimes, this won’t even work which was the case with a new HP 800 G1 SFF I was working on. As a last resort, I knew the NIC was Intel I217, so I grabbed the latest driver pack from Intel themselves:
https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=18713&lang=eng&OSVersion=Windows%207%20%20*&DownloadType=Drivers

After downloading an extracting all these drivers, I attempted the brute force method. Following these instructions: http://www.niallbrady.com/2011/08/31/missing-nic-driver-in-winpe-boot-image-no-problem/ I loaded the lot onto a USB drive, and just started loading driver after driver with the command ‘drvload filename.INF’ and then checking if the network was there using the ‘ipconfig’ command. About 10 drivers in, one of them took longer to load (e1d63x64.inf) and I had an IP address! I then loaded both the 32 and 64 bit versions into the boot images, and my task sequence to deploy Windows 7 was working.

If you’re not even getting as far as WinPE launching, then you’ve got a completely different issue, so start researching!