When deploying physical or virtual systems with a UEFI BIOS, at every deployment there will be a bootmgfw.efi file created. This is bad for two reasons: (1) there will be lot of files in the bootstore after a few deployments, (2) on Hyper-V Generation 2 VM's this will be top file in boot order, so PXE boot isn't active at next deployment. That way you need to "Move up" the Network adapter after each deployment. In this blogpost I describe how to edit the bootstore and remove the EFI files. Not that easy if you ask me. At the moment it's not clear to me is this' a bug, or choosen by default?
Warning: Removing entries in the bootstore can disrupt your VM. This because besides of Windows Boot Manager items (bootmgfw.efi) EFI SCSI and Network devices (disk, network) can be removed also!
Let's have a look at the steps needed to free up boot store, these are coming from http://jeff.squarecontrol.com/archives/184 but there's an error in it:
To view these duplicate entries, use the command: bcdedit /enum firmware
1. Save a copy of the current BCD system store by running the following command: bcdedit /export newbcd
2. Make another backup of the system store, just in case: copy newbcd bcdbackup
3. Enumerate the firmware namespace objects in the BCD system store, saving to a text file: bcdedit /enum firmware > enumfw.txt
4. Open the enumfw.txt file in Notepad, and delete all lines except those with firmware GUIDs. Delete the {fwbootmgr} and {bootmgr} lines as well – you only want the GUIDs.
5. Rename the edited enumfw.txt file to a command file called enumfw.cmd.
6. Insert the following BCDEDIT command in front of each identifier in the enumfw.cmd file: bcdedit /store newbcd /delete
Let's wait here because the command mentioned is not right. Because of an error you get the message: "The boot configuration data store could not be opened". This because for two reasons: (1) the QUIDs mentioned must be within double-quotes, (2) the /f qualifier is missing (optional).
When using both double-quotes and /f qualifier in the end it's working fine.
No error message this time: "The operation completed successfully"! Let's start edit the bootstore and remove the EFI files furthermore.
7. Add the following command to the end of the enumfw.cmd file, then save it: bcdedit /import newbcd /clean
Note: The /import /clean option deletes all NVRAM entries and then re-initializes NVRAM based on the firmware namespace objects in the newbcd BCD store.
8.Run the enumfw.cmd file and reboot the system afterwards (optional). This time it will be working fine.
Use bcdedit /enum firmware to verify that the extra entries are gone. Just great that all bootmgfw.efi files are removed now!
Still I would like to know is this' a bug, or choosen by default? In this case I'm using around 10 Virtual Machines (used as Microsoft RDS hosts), but what to do when having many many more VM's? That seems like a lot of work to me? (to be continued)
Source:
Clearing Duplicate Firmware Objects in UEFI BIOS
bcdedit: The delete command specified is not valid
Great news! System Center Technical Preview is available now! It can be download on Microsoft TechNet if you have a TechNet or MSDN subscription. Lucky me I have one because of my Microsoft Certified Trainer (MCT) status. Let's have a look at the downloads available:
-Windows 10 Technical Preview
-Windows 10 Technical Preview for Enterprise
-System Center Technical Preview (Data Protection Manager, Orchestrator, Operations Manager, Virtual Machine Manager, Service Manager) > No Configuration Manager this time!
-Windows Server Technical Preview
-Windows Server Datacenter Technical Preview
-Microsoft Hyper-V Server Technical Preview
Just connect to Microsoft TechNet and download the bits!
At customer location we're using multiple Hyper-V hosts, managed by a System Center Virtual Machine Manager (SCVMM) server. On multiple Virtual Machines (VM's) we like to deploy a server operating system with ConfigMgr. Trick is, when booting Hyper-V VM's from a PXE server, nothing seems to happen. Within Hyper-V Manager > BIOS config, the "Legacy Network adapter" is on top. Just have a look at the comment: "Use a legacy network adapter to perform a network-based installation of the guest operating system."
Because "Legacy Network adapter" is displayed here, we're thinking that the right network adapter is installed in the VM. Unfortunately this is not the case. Within VM properties in SCVMM there's a choice to use a network adapter or legacy network adapter. By default the network adapter is installed. With this network adapter no PXE boot can be done. Just delete this network adapter or choose "not connected" and add a new legacy network adapter.
After that PXE boot is working immediately. Just remember the following: Hyper-V supports booting a VM from the network using the F12 option. Trick is that you must use the legacy network adapter. The regular network adapter is synthetic and therefore not available at boot time. You have to remove the existing network adapter and add a new legacy network adapter. With that you're done!
Sponsor post
New: Veeam Task Manager for Hyper-V
Free tool for real-time Hyper-V performance monitoring
Improve troubleshooting in your Hyper-V environment by seeing what Windows Task Manager doesn’t show you. Veeam Task Manager for Hyper-V displays a real-time view of CPU and memory at the individual VM level so you can identify which VMs are using the host resources.
This lightweight tool is portable so you can run it from any USB device for emergency troubleshooting. No installation or integration needed!
Get the critical visibility you need.
Download the FREE Veeam Task Manager today
Sponsor post
Today I received a message from Veeam that a Free Study Guide for the Microsoft 74-409 exam on Server Virtualization with Windows Server Hyper-V and System Center is available!
With this new study guide you can learn how to create and configure virtual machine settings, virtual machine storage and virtual networks. This guide covers each of the Microsoft exam objectives.
Just great if you ask me so use it to your advantage!
Today I had several times a BSOD in Windows 8. BSOD stands for "Blue Screen Of Death", and is the result of an error. My system (with Windows 8 RTM) is installed a month ago and I've installed the Hyper-V role in it. With Hyper-V on Windows 8 it's possible to install Virtual Machines without the need to install VMware Workstation or Oracle VirtualBox.
Last days there were some Windows updates installed and a reboot was needed. After this reboot I had multiple BSOD screens and no quick solution to fix it. Looking for the error message in Event Viewer
"DRIVER_IRQL_NOT_LESS_OR_EQUAL (bridge.sys)"
it seems that Hyper-V was failing on the driver. A quick workaround for this is to plugin a network cable and deactivate Wi-Fi.
A better way to fix this is change the Virtual Switch settings in Hyper-V Manager. Just look at the settings configured at your external connection, and untag "Allow management operating system to share this network adapter" in Connection type. After that my system is stable again and no unexpected reboots are longer present. Hope there is a Microsoft fix for this issue soon.
Update: I don't know if it matters, but configure the Hyper-V connection type on your fixed NIC adapter, not on your Wi-Fi adapter. For it seems some people still have issues otherwise.
Update 23-7-2013: For it seems the issue is still valid. I'm using Internet Connection Sharing (ICS) for a while now, so no need to configure a bridge. With ICS you can share internet from a fixed or Wi-Fi connection to the vEthernet connection. Much better that way, and no BSOD issues on the bridge.sys driver.
In ConfigMgr 2007 it is difficult to have a true High Availability (HA) solution. This because it isn't supported yet in ConfigMgr 2007; we must wait for ConfigMgr 2012 for that. There are possibilities however with dividing roles on multiple servers, or install it on a Virtual Machine. Then there will be possibilities with VMware ESX (VMotion) or Microsoft Hyper-V (Live Migration) to create a HA environment. ConfigMgr 2007 is not HA then, but the platform on which it's running is.
First have a look at the roles/components available:
- SMS Provider: The interface between the Configuration Manager console and the site database;
- Management Point (MP): The site system role that serves as the primary point of contact between Configuration Manager clients and the Configuration Manager site server;
- Proxy Management Point (PMP): A management point residing in a secondary site that proxies most MP data between clients within that site and the primary site where they are assigned;
- Server Locator Point (SLP): A site system role that locates management points for Configuration Manager clients;
- Fallback Status Point (FSP): A site system role that gathers state messages from clients that cannot install properly, cannot assign to a Configuration Manager site, or cannot communicate securely with their assigned management point;
- Reporting Point (RP): A site system role hosts the Report Viewer component for Web-based reporting functionality;
- Reporting Services Point (RSP): A site system role assigned to a computer running SQL Server Reporting Services. It provides tools and resources that enable advanced report generation from the Configuration Manager console;
- Software Update Point (SUP): A site system role that is used to integrate with Windows Server Update Services (WSUS);
- Distribution Point (DP): A site system role that stores package source files for deployment to clients;
- Protected Distribution Point (PDP): A Configuration Manager distribution point that has boundaries configured to prevent clients outside the boundaries from retrieving packages;
- Branch Distribution Point (BDP): A Configuration Manager site system that stores package source files and is designed to be located in a distributed location with limited network bandwidth or a limited number of clients;
- Asset Intelligence Synchronization Point (AISP): A site role that is used to connect to System Center Online to manage Asset Intelligence catalog information updates;
- System Health Validator Point (SHV): Used with Network Access Protection to provide remediation;
- Out of Band Service Point (OoBSP): A site system role that discovers, provisions, and manages desktop computers that have management controllers (Intel Active Management Technology (AMT)-based computers);
- PXE Service Point (PSP): A site system role that has been configured to respond to and initiate operating system deployments from computers whose network adapter is configured to allow PXE boot requests;
- State Migration Point (SMP): A site system role that stores user state data when a new system is built for that user.
- Microsoft Deployment Toolkit (MDT): Have a look at this for the possibilities: MDT integration in ConfigMgr 2007
It's also good to know that large environments needs a Central Site for managing other ConfigMgr Sites:
- A Central Site is a ConfigMgr Primary Site that resides at the top of the ConfigMgr hierarchy. All Database information rolls from the child to the parent and is collected by the Central Site’s ConfigMgr Database. The Central Site can administer any site below it in the hierarchy and can send data down to those sites as well.
When setting up a new ConfigMgr-HA environment, think about this:
- If a Central Site is needed, then use it only for the SUP role and maybe the SLP role. It's a best practice not to use the Central Site server to manage clients. Rather, use the Central Site server as an empty root with a Child Primary beneath it to manage any clients within the same site location or site boundary;
- If a Primary Site server is needed, devide the ConfigMgr setup and ConfigMgr database on different servers. Install the RSP role on the ConfigMgr database server then;
- SMS Provider: Can be installed on the Central Site server and/or Primary Site server. It cannot be installed on a clustered SQL server database server or on the same computer as the SMS Provider for another site. There can be only one SMS Provider installed per site;
- Management Point: Must be installed on the Primary Site server, not on the Central Site server. It is possible to use Network Load Balancing (NLB) for this role, if they are in the same subnet;
- Reporting Services Point: Instead of installing the RP role on the ConfigMgr server, the RSP role can be installed on the (clustered) SQL server;
- Software Update Point: Can be installed on the Central Site server and/or Primary Site server. It is possible to use NLB for this role, if they are in the same subnet;
- Distribution Point: Can be installed on the Primary Site server, but don't use it on the Central Site server. Most of times installing multiple DP's is the best option, because NLB is not supported for this role;
- PXE Service Point: Can be installed on the Primary Site server, but don't use it on the Central Site server. There can be only one PSP role installed per site.
For having ConfigMgr-HA I recommend this:
- 1 Primary Site server (on a Virtual Machine for HA) with the following roles/components: SMS Provider, SLP, FSB, (MDT);
- 2 Distribution Points (minimum) with the following roles: DP, PSP (there can be only one PSP installed per site);
- 2 servers in a NLB setup with the following roles: MP, SUP;
- A (clustered) SQL Server with the ConfigMgr database and RSP role.
When dividing roles (without HA) I recommend this:
- 1 Primary Site server (on a Virtual Machine) with the following roles/components: SMS Provider, SLP, FSB, MP, (MDT);
- 2 Distribution Points (minimum) with the following roles: DP, PSP (there can be only one PSP installed per site), SUP;
- A (clustered) SQL Server with the ConfigMgr database and RSP role.
Sites used, and handy information:
I hope things are clearer with this blog now. Please feel free to put comments on this blog and ask for additional questions!
