Tag Archives: windows

Windows 10 – Converting To UEFI

Leave a reply

Background

With Windows 10 preparing to shuffle off this mortal coil, I’m trying to decide how to handle it. Based on the Windows 11 hardware requirements (TPM, and an unsupported CPU i7-6800k/Broadwell-E) I’m likely going to move to Zorin OS. But I’m planning on dual-booting as a transition (as well as if I hit any issues gaming), so eventually Zorin will be the main driver, and the Win10 image just for emergencies.

Unfortunately I’ve running Win10 since the beginning, so its a little rough around the edges. The main thing to change is move from MBR to the shiny UEFI compatible GPT boot partition.

Unfortunately the handy mbr2gpt.exe tool was hitting the “OS Not Found” problem, and apparently the Windows Recovery Environment [WinRE] never worked, so here we go!

Fixing the Windows Recovery image

Download the Windows Media Creation Tool and create an ISO image for installation on another system.

Open the ISO archive and extract Sources\install.esd

Usually Windows Pro is number 6, but just to check

g:\>dism /Get-WimInfo /WimFile:install.esd

Deployment Image Servicing and Management tool
Version: 10.0.19041.3636

Details for image : install.esd

Index : 1
Name : Windows 10 Home
Description : Windows 10 Home
Size : 15,236,014,793 bytes

Index : 2
Name : Windows 10 Home N
Description : Windows 10 Home N
Size : 14,461,663,459 bytes

Index : 3
Name : Windows 10 Home Single Language
Description : Windows 10 Home Single Language
Size : 15,238,702,954 bytes

Index : 4
Name : Windows 10 Education
Description : Windows 10 Education
Size : 15,586,696,335 bytes

Index : 5
Name : Windows 10 Education N
Description : Windows 10 Education N
Size : 14,821,374,633 bytes

Index : 6
Name : Windows 10 Pro
Description : Windows 10 Pro
Size : 15,583,732,666 bytes

Index : 7
Name : Windows 10 Pro N
Description : Windows 10 Pro N
Size : 14,818,128,477 bytes

The operation completed successfully.

Now extract the encrypted image as a wim file

g:\>dism /export-image /SourceImageFile:install.esd /SourceIndex:6 /DestinationImageFile:install.wim /Compress:max /CheckIntegrity

Deployment Image Servicing and Management tool
Version: 10.0.19041.3636

Exporting image
[==========================100.0%==========================]
The operation completed successfully.

Mount the image (wait for the mount to complete before the next step)

g:\>md tempMount

g:\>dism /mount-wim /wimfile:"install.wim" /index:1 /mountdir:"tempMount" /ReadOnly

Deployment Image Servicing and Management tool
Version: 10.0.19041.3636

Extract the needed file (Winre.wim) from Windows\System32\Recovery, move it to C:\Windows\System32\Recovery register it, and enable it

reagentc /setreimage /path C:\Windows\System32\Recovery
reagentc /enable
reagentc /info

Rebuild BCD

Now boot into recovery (shift + reboot), select Advanced, and boot into the shell. Then run

bootrec /rebuildbcd

Convert to GPT

Assuming that runs successfully, you should now be able to run (do /validate first!!)

mbr2gpt.exe /convert /allowFullOS

In my case it left the “System Reserved” partition alone, resized the OS partition, and created an EFI partition. At which point Windows Blue Screened (so no captures) and eventually rebooted.

All came back, and we are now in the shiny world of EFI 🙂

Setting up Awesome Miner for XMRPool

Leave a reply

While playing around with Monero mining I decided to give Awesome Miner a try.

While trying to provision the XMRPool.net pool, I had a bit of trouble getting it working.

[2018-01-22 17:02:25] Using JSON-RPC 2.0
[2018-01-22 17:02:26] NVML GPU monitoring enabled.
[2018-01-22 17:02:26] NVAPI GPU monitoring enabled.
[2018-01-22 17:02:26] 1 miner thread started, using 'cryptonight' algorithm.
[2018-01-22 17:02:26] HTTP request failed: Empty reply from server

 

The issue is that you need to instruct it to use the stratum protocol, so the server URL should be constructed as follows:

stratum+tcp://<Server URL>:<Port>

So the pool config will look like this:

 

And with that we are up and running:

[2018-01-22 17:06:25] Using JSON-RPC 2.0
[2018-01-22 17:06:25] Starting on stratum+tcp://mine.xmrpool.net:5557
[2018-01-22 17:06:26] NVML GPU monitoring enabled.
[2018-01-22 17:06:26] NVAPI GPU monitoring enabled.
[2018-01-22 17:06:26] 1 miner thread started, using 'cryptonight' algorithm.
[2018-01-22 17:06:26] Stratum difficulty set to 5000 (5)
[2018-01-22 17:06:26] GPU #0: Gigabyte GTX 1070, 7454 MB available, 15 SMX
[2018-01-22 17:06:26] GPU #0: 960 threads (9.875) with 60 blocks
[2018-01-22 17:06:27] API open to the network in read-only mode on port 4028
[2018-01-22 17:06:54] accepted: 1/1 (diff 5.108), 34.67 H/s yes!

Remote Desktop Protocol [RDP] and OS X

Leave a reply

So, I had occasion to try and connect to a windows machine from my Mac. As a long time windows user, my default goto for this is of course Microsoft’s Remote Desktop Protocol. And as luck would have it, OS X/macOS ships with a client called Remote Desktop Connection for Mac (version 2.1.1 build 110309) though from the copyright notices this looks like it hasn’t been touched since 2010… and that is the problem.

On attempting to connect to anything half way recent e.g. Server 2012, Win10, etc. you are thrown the very helpful error “Remote Desktop Connection cannot verify the identity of the computer that you want to connect to. Try reconnecting to the Windows-based computer, or contact our administrator.”

It turns out that Microsoft improved the security of RDP (always a good thing) to make use of something called Network Level Authentication [NLA]. This happened the same time Windows moved from Terminal Services to Remote Desktop Services.

What’s the difference? When connecting to a Terminal Server, a user starts a session and types in their credentials. When using an RD Session Host server, a user typically enters credentials into a client-side dialog box. NLA forces the client computer to present user credentials for authentication before the server will create a session for that user.

Because of that process, it’s sometimes called “front authentication.” Servers that are running Windows Server 2008/Vista or later, and clients running Windows XP SP3 or later, support NLA. Because NLA relies on a technology called Credential Security Support Provider [CredSSP] Protocol, if you’re using a Remote Desktop Protocol [RDP] client for another OS, you’ll need a client that supports NLA.

Microsoft Remote Desktop Connection Client for Mac doesn’t.

Fortunately there is an alternative that does. Via the AppStore, search for ‘Microsoft Remote Desktop’ – Version 8.0.36 (Build 27228) is what I have today. Install this, try and connect to your Windows machine (Win10 for me) and you are in business.