Month: February 2016
A lot of download sites present checksums for you to check that what they host is actually what you download. I, for one, have always been dubious of such measures, and the recent Linux Mint breach proves what I’ve always suspected.
Continue reading “Linux Mint Breach Lessons”
[Re-blogged from The Guardian]
Apple’s celebrated fight with the FBI over the security of its encrypted iPhones has shone the spotlight on an old and obscure federal law from 1789 known as the All Writs Act (AWA).
The AWA is a short little statute, giving federal courts the power to “issue all writs necessary or appropriate in aid of their respective jurisdictions and agreeable to the usages and principles of law.”
The FBI argues that the AWA empowers a court to order Apple to create custom software to circumvent the security on an iPhone possessed by one of the San Bernadino shooting suspects.
Passed by the First Congress in 1789, this little law is a piece of Swiss Army knife legislation that the FBI is trying to turn into a giant sword, out of all proportion to what it is supposed to do. But if we want to make sense of the current security and privacy controversy pitting the FBI against the tech giant, it helps to understand what the AWA is and what its limits are.
[Last Updated: 1 Jan 2017]
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.
Update:
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.
Some References for this update:
“, (see comment by Jayantha 18 March 2014 at 04:06)
Good notes on deployment at https://www.windows-noob.com/forums/topic/6250-how-can-i-deploy-windows-8-in-uefi-mode-using-configuration-manager-2012/
Under Apply Network Settings, add an entry for Network Settings and be sure to put in the suffix “domain1.ci.longmont.co.us” on the DNS tab.
Under the Setup Operating System, add “Run Command Line” step “Disable DEP”. In the Command line section, put “bcdedit /set nx alwaysoff”. On the Options tab, place a checkmark by Continue on error.
See http://blogs.technet.com/b/configurationmgr/archive/2014/04/28/how-to-ensure-that-windows-installs-on-c-during-a-system-center-2012-configuration-manager-osd-task-sequence.aspx about assigning drive letters.
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.
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.
After pulling down the image, it seems to ignore some important personal security settings, such as for Wi-Fi Sense. For now, at least until certain policies can be put into place, manually change the settings using http://www.techrepublic.com/article/windows-10-violates-your-privacy-by-default-heres-how-you-can-protect-yourself/ as a guide.
Also, you can use the free program GwxControl to have greater control with less hunting.
Update: Some settings can be standardized by following procedures at http://www.tenforums.com/tutorials/2110-default-user-profile-customize-windows-10-a.html. If the image has already been deployed on a machine, you do not need to re-run the setup, but force sysprep to go into audit mode. Use this unattend.xml to preserve drivers:
<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
<PersistAllDeviceInstalls>true</PersistAllDeviceInstalls>
</unattend>
Save as C:\unattend.xml. Next open a command prompt with Administrator privileges and run:
sysprep /generalize /audit /reboot /unattend:"C:\unattend.xml"
Note: You cannot save taskbar settings for whatever reason. In spite of documentation, however, it looks like the Start menu is preserved.
You can check an image by mounting it via the DISM command:
md c:\test
md c:\test\img1
md c:\test\img2
Dism /Mount-Wim /WimFile:C:\Users\johnd\Desktop\Win10x64base.2015.12.28.wim /index:1 /MountDir:C:\test\img1 /ReadOnly
Dism /Mount-Wim /WimFile:C:\Users\johnd\Desktop\Win10x64base.2015.12.28.wim /index:2 /MountDir:C:\test\img2 /ReadOnly
To umount images:
DISM.exe /Unmount-Wim /MountDir:C:\test\Img1 /discard
DISM.exe /Unmount-Wim /MountDir:C:\test\Img2 /discard
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.
So, I’ve been busy lately with, among other things, repurposing my Raspberry Pi for Bitcoin mining. Yet, in spite of a proliferation of guides on how to do Bitcoin mining on the Raspberry Pi, I struggled a bit with getting it all setup. So, while this is mostly about getting it all setup, this article is as much about the pitfalls to avoid. Continue reading “Bitcoin Mining on the Raspberry Pi”