Microsoft recently introduced Bash on Ubuntu on Windows 10 for developers. Does it work?
Not long ago, I was unable to use TeamViewer to remote into my laptop to use ssh. So, I attempted to install putty and other tools in order to ssh into a server from a Windows 10 machine. My disappointment in how it worked was even larger than I would have anticipated.
It seems weird that we are decades into using the Internet, and Windows tools still really lack at doing server support. Apparently, I am not alone, though, and Microsoft has included a bash shell from no less than Canonical, the company behind Ubuntu, in their latest developer release.
And, I even heard it would support ssh.
This gave me a burning desire to at least give it a try.
The downside is that I had to get my computer back onto the Windows Insider Program, which meant re-enabling a lot of the more chatty portions of Windows 10 that were locked down for privacy reasons. However, that’s part of the deal that you are supposed to give feedback and such as part of the program, so this is actually a case where some of these otherwise intrusive elements makes sense.
Well, I finally got the Insider preview installed, and I enabled the Subsystem for Linux (Beta). You can read more about the entire procedure at FossBytes‘ “How To Install And Run Bash On Ubuntu On Windows 10 Right Now“. I opened a command prompt and typed “bash” and pressed [Enter]. The installation took a little longer than I had anticipated, but a while later I had an actual bash shell.
OK, but is this anything like opening a terminal in Linux? Can I really ssh and paste a password into the shell instead of typing everything on the command line like it’s 1993?
Sure enough, I opened a browser and copied the password from LastPass and pasted it into the bash window and I was on! Not only did ssh work, but the entire command window behaved similarly to a terminal window in Linux!
OK, I’m not giving up Arch tomorrow, but at least if I’m stuck on a Windows box, I can at least use familiar tools and not have to rely upon programs that simply don’t live up to the expectations.
“Should I switch to Windows 10?” is a question a get a lot. Here’s how to find out.
“Should I switch to Windows 10?” For a lot of people who ask this question, they are really asking whether or not they should upgrade their current computer running Windows 7, take the time to learn a new user interface (that frankly is often half-baked) and take a chance that the programs they currently are now using will either no longer work at all or will need an upgrade.
I’ve actually had dreams (nightmares?) lately about Microsoft license activation, believe it or not, as it is such a pain in the ***. Both Microsoft Windows and Microsoft Office can get to the point where they cannot or will not talk to the KMS server and grab a license for one reason or the other. So, this is how to force the issue when you have enterprise versions of this software.
One scenario is where Windows quits talking to the KMS server, goes beyond the grace period and then declares that this copy of windows is not genuine. You can try to activate it, but it will refuse because it is out of the grace period. Of course, it is outside of the grace period because it did not activate, so this causes a bit of a catch-22.
The way to break out of the cycle is to extend the grace period. You do this via the “rearm” command. For example, open a command prompt with elevated privileges and type:
That will rearm activation, thus extending the grace period, and then activate windows (it assumes KMS is online).
These are my notes from working on Windows 10 UEFI SCCM boot images. They are the result of experimentation, so take everything with a grain of salt and realize everything is subject to change.
[Last Updated: 1 Jan 2017]
Reference Computer & Capture
Ensure that the SCCM capture media boots via UEFI in case it needs to reboot. Turn off Enable Legacy Option ROMs in the BIOS just to make sure.
Apparently, there is an issue with the size of the EFI partition if the default is used. Create partitions either from another image or from Linux and apply them and then install Windows 10. This will ensure that both Recovery and operating system directories are correctly captured and applied.
You should have “Capturing volume 1 of 2” and “Capturing volume 2 of 2” for task sequence “Capture the reference machine”, else you may have not booted UEFI before the capture. If instead you get “Capturing volume 1 of 1”, check boot settings and uncheck any Windows Manager entries.
I should state that when it did capture multiple partitions, it did so inconsistently. It was more or less every other time it would capture 1 — 2 and 2 — 2 vs 1 — 1. However, the server guys ran a patch a few months ago, and it now only does 1 — 1 period. I suspect that you might be running the same patch level.
Having said that, UEFI and Windows 10 still works. Since that was more or less what the article was about, I suppose you can quit reading after this paragraph because all you have to do is in your task sequence for deployment, you still create the partitions for EFI, etc, in Format and Partition Disk and simply deploy your image to the last partition (or OSDisk). You honestly don’t seem to lose anything unless you try to use Windows 10 Reset your PC option, as testing it out had it working the first time on a given computer only.
Some details of what I’ve learned since writing the original article:
1. Somewhere along the way, SCCM stopped capturing multiple partitions. There are ways to force it, but using the simplest create capture media no longer does it at all that I can tell. Even when it did work, it was inconsistent at best. It appeared to, more or less, capture 2 partitions every other time (but not always).
2. SCCM does not natively like multiple partitions. Sure, it can create them, but there are workarounds all over the web to do anything meaningful with them beyond that. Most of the time, the advice is to simply use something else if you really, really want to create and deploy multiple partitions.
3. If you simply want a UEFI boot, simply create the appropriate partitions in the Format and Partition Disk step and then deploy your OS image to OSDisk. Apparently, it is Windows 10 and the BIOS that will handle the UEFI without further ado. In the worst case, the Dell BIOS allows you to force UEFI, and some machines work better with legacy disabled. Forcing the Dell BIOS into UEFI mode and disabling legacy mode on some models, booting UEFI on the USB task media stick, creating the proper partitions and deploying Windows 10 to the last partition all seems to make it work fine.
4. SCCM especially does not like multiple OS partitions, and so we are testing it out by using two already existing images and deploying them using two different task sequences (and then manually running bcdboot if we want the boot menu). Doing otherwise either has the second OS overwriting the first or the entire sequence stopping after the first is configured. Obviously, we put the Format and Partition Disk step in the first task sequence but not in the second.
For deploying the image, in the Apply Operating System task sequence step, though, you only need the 2 – 2 image of the captured image package (.WIM) file. Do a Apply Data Image task for the recovery partition (1 – 1).
Partition layout should look something like:
Task sequence will not install on an unpartitioned drive. Create a 450MB Recovery partition (NTFS) and a 100MB EFI partition (FAT32) at the beginning of the disk. The rest can be named anything and formatted NTFS.
Note that the recovery partition is not required. Some things might act wonky without it, but if you can dump it, I suggest you do so. SCCM is a royal pain when it comes to capturing both partitions.
Note the sizes. I believe some of the pain I encountered was due to an illegal partition size created by Windows OOB. Somehow create the Recovery and EFI partitions and then install Windows.
Boot Image Issues
If you create a task sequence with an x86 boot image but the stick is booting x64, then the UEFI SCCM task sequence will attempt to copy down the boot image called for. Unfortunately, it does this on its own and before the task sequence begins. Of course, the task sequence partitions and formats the hard drive, so the boot image is immediately lost. You can tell it will copy down the boot image because SCCM will ask you to reboot before running the actual task sequence.
If you change an x86 task sequence so it has a UEFI SCCM x64 boot image on a stick created with an UEFI x64 boot image, it will not copy down the boot image, which gets around that particular problem. However, the end result will be a non-bootable system, it would appear.
All of the documentation I have found state that you need to use an x64 boot image to deploy 64 bit systems and an x86 boot image to deploy 32 bit systems. Since we have been deploying 64 bit systems with an x86 boot image in the past (MBR only, naturally), it would appear we were simply lucky.
In general, it seems that the initial capture of an x64 UEFI image will only capture the main partition. However, if you use that image to gen the main partition of a working UEFI system, you can then sometimes get the capture task sequence to capture both restore and main partitions. [See update previous.]
I still believe it is related to the missing TSMBAutorun.exe on the capture stick. There is supposed to be one under each of the i386 and x64 subdirectories of SMS, but only the i386 subdirectory has it.
You need the Dell service tag number for a computer, but the machine is not currently in tech’s possession. However, it is up and on the domain.
From a command prompt (does not need to be admin), type:
wmic /user:\administrator /node: bios get serialnumber
Substitute the remote computer’s name for <domain> if logging in as local administrator.
It will prompt for the administrator’s password for the remote computer, and, hopefully, spit out the info you need.
Network issues can interfere with this, though, so if you don’t succeed at first, try again at a later time.
It seems that a problem that plagued beta versions of Windows 10 has crept into the mainstream. I am convinced that there is an update that causes this, although, because we no longer have control over updates, it is really difficult to know which one. Essentially, the start menu works when you first install it, but somewhere along the line Windows 10’s Start Menu quits working. Continue reading “Windows 10’s Start Menu Quits Working”→
How to stop Edge, or whatever your default browser is, from opening up when you first login or connect to the network.
Autostart programs tend to be annoying, but they are no less annoying when they are Microsoft programs. I’m not talking about required services that the operating system needs to function, but rather things like autoupdaters or other programs that just hang around just in case they are actually needed. Still, even these are better than a web browser that pops up whenever you login to the network. Continue reading “Windows 10 Autostarts Edge When You Login”→