Install 64bit Windows OS (7+) on older 64bit Mac's (2007 32bit EFI white MacBook)

When working at HP I came up with a Windows Vista restore/install solution that worked using Windows PE for both 32bit and 64bit architectures.  A few years ago, I tried the same solution against my 2007 White MacBook, and, lo and behold, I was able to install 64bit Windows 7 on my MacBook.  I didn't have the time to document it as it was just for curiosity, but I am doing so here now because I am repurposing my MacBook as a 3D Printer server.

To start, you need a 32bit Windows install on DVD and the version of Windows you want to install on a USB key (or another DVD).  This is because the MacBook will not DVD boot off of a 64bit install, or the USB key.

1) Boot off the 32bit install DVD.

2) Shift-F10 into a command prompt.

3) Format your hard drive/partition.  Make sure you only have 1 partition.  You may need to use diskpart, whenever I used the Windows Setup it created 2 partitions which causes 0xc000000f errors on startup because the BCD file is configured to look for [boot]\path\to\wim which doesn't reside on the boot drive.

4)  Robocopy everything from the DVD to the HDD. (My DVD drive came up as E:)
Robocopy E:\ C:\ /MIR

5) Insert your Windows x64 USB/DVD and copy over *just* the install.wim from %USB%\sources\install.wim to your C:\sources\install.wim

6) Eject the DVD and reboot your computer off the hard drive.  Do the install as usual.

This trick only seems to work when you have both 32bit versions and 64bit versions of the SAME software.  It does not appear to work if you try, for instance, to use the Windows 7 Enterprise x86 and Windows 7 Ultimate x64.

HPSIM - Disable system monitoring for 1 hour

This script will disable monitoring in HPSIM for 1 hour.

APPV5 - Sequencing FolioView ICD/CCI with AppV5. (Issues with VFS not redirecting)

When sequencing FolioView 2012 or 2015 with AppV5 SP3, launching the application after sequencing generates an error:

---------------------------
Folio Views
---------------------------
No object handler is registered for this object type.
---------------------------
OK
---------------------------

This error seems to appear because VFS either isn't fully loaded by the time Views.exe is loaded so the program/dlls actually traverse down a non-virtual path, or they somehow break the AppV bubble and don't find whatever it is they are looking for.  To correct this issue, you need to create a symbolic link to the VFS'd program directory from where the actual directory is supposed to reside.  For instance, I sequenced FolioView to:

C:\Program Files (x86)\CIHI

To produce the error, I launch my command like so (this is what AppV5 automatically puts into the shortcut):

%ALLUSERSPROFILE%\Microsoft\AppV\Client\Integration\C05CC38A-D146-442B-B97F-89E8867DF0CE\Root\VFS\ProgramFilesX86\CIHI\CIHI_PUB_2015\Cihi32\Views.exe -L1033 -cSoftware\CIHI\2015\ICD10\English -i"\\fileserver\CTX_APPS\FolioView2015\cci_2015_eng.sdw"

I then get the error message.

If I mklink /d "C:\Program Files (x86)\CIHI" D:\AppVData\PackageInstallationRoot\C05CC38A-D146-442B-B97F-89E8867DF0CE\0CA628F4-AC24-4981-9B52-DA

B4445B8ECF\Root\VFS\ProgramFilesX86\CIHI

Then launch the application via the 'native' path:

"C:\Program Files (x86)\CIHI\CIHI_PUB_2015\Cihi32\Views.exe"  -L1033 -cSoftware\CIHI\2015\ICD10\English -i"\\q9-v-citrix-lif1.healthy.bewell.ca\CTX_APPS\FolioView2015\cci_2015_eng.sdw"

It works without any error messages and without issue.  

Here's a short clip of the error and the 'fix':

I did a stack trace of the error message and it comes up like so:

There are several calls that appear to look for files (nfomgr4, fcctrl4, mpr, davInt) that maybe generating the error message, but, I am not skilled enough at WinDBG at this time to be able to dig deeper.  Either way, there appears to be a limitation within AppV5 that prevents this program from operating correctly.  The same program works in AppV 4.6 without issue though, so it appears AppV5 sill has some work to go to get full compatibility with PITA applications.

Here's the application working fine in AppV 4.6.  The application was installed identically for both AppV versions.

AppV5 - Data Precache script (used for XenApp)

This is the AppV5 Data Precache script we use to load our AppV5 packages on our Citrix XenApp servers.  Because we use PVS and store the AppV package installation root folder on a persistent disk, we sometimes encounter issues that require us to 'clean up' the package installation root folder before the AppV5 packages will load.  What this script attempts to do is setup AppV5 as if it's a new install, grab any packages from the publishing server, then, if sharedcontentstore is disabled, fully mount/load the packages.

AppV5DataPrecache.cmd

PVS Target Device Update Script -- Supplemental File, disableddnsregistration.ps1

Our PVS servers are multi-homed with the Provisioning NIC on a seperate VLAN.  Because of how our network is structured, our Provision NIC could register its DNS, but client computers would not be able to connect to it as it is a segregated network.  This script sets the Provision NIC to NOT register to DNS.