2

So... long story short I'm working on automated installations of Windows Server 2012 R2 on systems with GPT drives both physical and virtual. I haven't brought the disk back down stairs to the physical box yet, but my VMs aren't working. Here are the symptoms (all VM, no physical):

When I try to install Windows 2012R2 manually, it runs though the upgrade process rather than an install process. It seems to think that Windows is somehow installed despite the hard disk not being partitioned or formatted. It doesn't make much sense to me. I have entered the console in the installation and confirmed that the C Drive doesn't exist. Disk 0 is fully free and the only volume that exists is the D Drive (DVD).

When I try to install using my automated method I start in a Windows PE environment running a C# program I created. This takes some input and spits out an unattend.xml file which is read during the Windows installation. The program is creating a harddrive that is 100 GB. Some files are copied over but there is atleast 80 GB still free on that drive. There is also an extra 40 GB on the disk (it is 140GB total). In the 2012R2 setup the system will get to the point of showing the progress screen then immediately fail stating that there is a hard drive issue. When I look in the logs, the system seems to be convinced that the hard drive is not big enough even though it seems to read it just fine and it clearly is large enough.

Please note that the automated install works on an MBR system. The only change I'd need to make to get it back to MBR is to not run the GPT command on DiskPart. I'd also need to switch the machine from EUFI to BIOS, or so I assume. Here is the diskpart command (may be slightly off, I'm converting from code, I can confirm that it does create a function C drive with 100GBs when run):

SELECT DISK 0
CLEAN
SELECT DISK 0
CONVERT GPT
CREATE PARTITION PRIMARY SIZE=100000
SELECT PARTITION 0
ASSIGN LETTER=C
ACTIVE
EXIT

The VM is set for EUFI, has a non-partitioned 140 gb thin provisioned drive, is set for Windows 2012R2, and if it's in BIOS and running a version of my software that does MBR format works just fine.

Any ideas? I'm a bit stuck and the problem is wordy enough that it's been difficult to search for on the internet.

  • out of curiosity, why are you not simply using MDT to build a litetouch deploy? – Jim B Jun 08 '15 at 19:08
  • I have no idea what that is. I'm a software engineer working on a platform deployment we've provided for over a decade now. The system has worked up to the point where I'm using UEFI and GPT (the new hardware uses UEFI). Unfortunately the systems people who were are my team are no longer with us. I'm not sure if switching technologies is a good idea at this point since this stage of the project is near completion, or was until I hit this wall. – Dropn Fbombs Jun 08 '15 at 19:54
  • I would suggest finding a professional admin to help with this. Reinventing the wheel is not the best solution. – Jim B Jun 08 '15 at 20:49
  • I've contacted another department to see if they can help (they have admins!). I'm not going to get into company politics but suffice it to say that this platform I'm working on deploys more than Windows so I'm not sure that MDT is the answer from my light research. I'll ask the other team once I can get them to help. I wouldn't say I'm re-inventing the wheel; the product worked fine until I found out about the UEFI/GPT requirement due to new hardware. I have a new theory that I'm preparing to test; looks like Windows 2012R2 sets up more than one volume at install... – Dropn Fbombs Jun 08 '15 at 21:05
  • If it's more OSes than windows that means that secure boot must be disdabled and the UEFI boot must support the bootloaders required – Jim B Jun 08 '15 at 21:21

1 Answers1

1

OK, I found the solution. Long story short a small 100MB partition needs to be generated before the installation if you are defining partitions rather than allowing Windows to do it. This is probably a unique case as the idea behind this program is to minimize the amount of time a user must touch the system during setup, so we create a partition and copy files over before Windows installs, and then run software installations once Windows starts up, removing the need for the person running the install to mess around with the system. Anyway the change is below:

SELECT DISK 0
CLEAN
SELECT DISK 0
CONVERT GPT
CREATE PARTITION EFI SIZE=100
CREATE PARTITION PRIMARY SIZE=100000
SELECT PARTITION 0
ASSIGN LETTER=C
EXIT