Some steps you can try if you encounter issues:

• Delete all VM snapshots and check if they are fully merged (so that no .avhd file exists)
• Check free disk space on all affected drives
• Check if the VM has set any special CPU settings
• Turn off the VM before moving (seems to help especially when moving from Windows Server 2019 to 2022)
• Do not write destination server name manually (use the dialog/assistant instead)

You have created an image of an SD card containing a Linux operating system. Afterwards you want to access and extract files of the image, but do not have a spare physical storage available or you are working on a virtual machine.

Unfortunately, it is not an ISO image which could be mounted by Windows itself or opened with 7-Zip.

Solution

Run Win32DiskImager to create your image.

Install ImDisk. It lets you mount Linux SD card images and similar drives under Windows.

Install Ext2Fsd. With this tool, you can access EXT2, EXT3, EXT4 and VFAT partitions under Windows.

Now mount your Linux partition with Imdisk and you should be able to access the files and folders via Windows Explorer.

Problem

WDS / PXE booting needs a unique GUID for every client workstation, e.g. if the PC has to be approved and given a name in the WDS console by the administrator.

Sometimes it may happen that not every GUID is unique. But duplicate GUIDs can lead to painful problems. E.g. if the workstation joins the domain automatically, the other machine which already exists in AD is overwritten. The result: One of both machines loses domain trust and has to be re-added to the domain.

Example with Zotac ID89, ID90, ID92 etc.: Every device seems to generate the same GUID by default. You see the GUID when you boot via PXE:

00020003-0004-0005-0006-000700080009

According to Zotac, this behavior is wanted and not a bug.

Workaround 1

1. A new, random GUID can be generated by using an AMIBIOS tool “AMI DMI Edit”.
2. Create a DOS boot stick, e.g. with Rufus.
3. Copy AMIDEDOS.exe of the AMI DMI Edit Tools Package to the stick.
4. Boot to DOS with the USB stick and run AMIDEDOS /u.
5. You should now have a freshly generated GUID.

Workaround 2

Use a registry key to tell WDS that certain GUIDs are banned. If these GUIDs appear again to WDS, it uses the MAC address as GUID.

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesWDSServerProvidersWDSPXE

More information here

Workaround 3

In Active Directory Users and Computers, you can modify or delete the netbootGUID attribute. You find it under [yourExistingWorkstation] -> Properties -> Attribute Editor. So if you PXE boot a new workstation, the GUID is not assumed as existing. Please note that this is not the recommended way because the problem is not really solved.

Notes

It might be useful in most cases to use both workarounds 1 and 2 to never accidentally overwrite an existing computer in your domain.

Sometimes WDS seems to block booting a PXE image after changing the GUID. Errors like this one may appear:

proxydhcp service did not reply to request on port 4011.

You can then use another LAN port (if available) or just temporarily disable the setting “administrator approval for unknown devices”.

Some sites provide Powershell scripts which can be used to delete every netbootGUID in your AD. I would not recommend this, because keeping the netbootGUID attribute of the computers can make later re-installing of Windows easier (the previous PC name is recognized automatically).

Problem

WDS / PXE booting needs a unique GUID for every client workstation, e.g. if the PC has to be approved and given a name in the WDS console by the administrator.

Sometimes it may happen that not every GUID is unique. But duplicate GUIDs can lead to painful problems. E.g. if the workstation joins the domain automatically, the other machine which already exists in AD is overwritten. The result: One of both machines loses domain trust and has to be re-added to the domain.

Example with Zotac ID89, ID90, ID92 etc.: Every device seems to generate the same GUID by default. You see the GUID when you boot via PXE:

00020003-0004-0005-0006-000700080009

According to Zotac, this behavior is wanted and not a bug.

Workaround 1

1. A new, random GUID can be generated by using an AMIBIOS tool “AMI DMI Edit”.
2. Create a DOS boot stick, e.g. with Rufus.
3. Copy AMIDEDOS.exe of the AMI DMI Edit Tools Package to the stick.
4. Boot to DOS with the USB stick and run AMIDEDOS /u.
5. You should now have a freshly generated GUID.

Workaround 2

Use a registry key to tell WDS that certain GUIDs are banned. If these GUIDs appear again to WDS, it uses the MAC address as GUID.

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesWDSServerProvidersWDSPXE

More information here

Workaround 3

In Active Directory Users and Computers, you can modify or delete the netbootGUID attribute. You find it under [yourExistingWorkstation] -> Properties -> Attribute Editor. So if you PXE boot a new workstation, the GUID is not assumed as existing. Please note that this is not the recommended way because the problem is not really solved.

Notes

It might be useful in most cases to use both workarounds 1 and 2 to never accidentally overwrite an existing computer in your domain.

Sometimes WDS seems to block booting a PXE image after changing the GUID. Errors like this one may appear:

proxydhcp service did not reply to request on port 4011.

You can then use another LAN port (if available) or just temporarily disable the setting “administrator approval for unknown devices”.

Some sites provide Powershell scripts which can be used to delete every netbootGUID in your AD. I would not recommend this, because keeping the netbootGUID attribute of the computers can make later re-installing of Windows easier (the previous PC name is recognized automatically).

Backup Software like Acronis Backup & Recovery causes your Hyper-V Virtual Machines to freeze. Guest OS is Ubuntu.

Sometimes this also happens when you restart your Hyper-V host or make a snapshot of your VM.

The VM itself displays error messages like “BUG: scheduling while atomic”.

Solution

The error message led me to this site, where it is mentioned that the error should have been fixed for about over a year now. I also tried to add the -Proposed entry in sources.list, but it did not help.

I upgraded to the latest Ubuntu Server version (14.04 LTS at the moment), but it did not help.

The final problem was I always left the Ubuntu default wizard setting by default (keep current file) when it asks for the boot / grub settings (menu.1st). So the system kept booting from an older kernel. In my case it was a 3.0 kernel, but in the meantime there exists version 3.13.

Additionally, as far as I know, Ubuntu will not always upgrade to the latest kernel itself by doing a distro upgrade.

Steps I did to solve the problem:

1. For safety reasons: VM snapshot or VHD copy
2. apt-get install linux-image-generic
3. apt-get autoremove
4. After the first or second step the wizard should ask you whether you want to keep your boot menu file. Choose the first option here (use a “new” one from the distributor).
5. Reboot and check the current kernel version (in the login info message or type uname -r).

The problem of ready-to-use cloud services like Dropbox, Skydrive etc. is, you never really know what the service provider does with your data, even if it is encrypted. ownCloud can run locally on your hardware and it is open source, so this way should be much safer.

This tutorial shows you how to install a Ubuntu VM on Hyper-V (or any other Hypervisor, or PC / server) in combination with LDAP / Active Directory.

Basic installation

First, create a new virtual computer in your Hyper-V environment, e.g. with 512 MB RAM or more. Ubuntu and ownCloud do not need too much resources. Choose a disk size according to how much space you need for your ownCloud storage.

Install the official Ubuntu ISO image, e.g. the server version of 12.04. It should work with default settings. Additionally, install SSH during the setup.

Log in and get the required packages via apt-get commands – see this site for details. Get ownCloud itself, also via apt-get – have a look here.

When the installation is finished, open http://[your-owncloud-server-ip]/owncloud in your browser and follow the wizard.

If you want to, you can do a first test now, e.g. use the ownCloud Windows client and try to connect with the Admin user.

SSL

If your ownCloud server is accessible from the internet, you should use SSL encryption to secure your data.

In the settings, also force ownCloud to use TLS.

Digicert has a good guide for creating the certificate request with your local Apache Server and how to integrate the final certificate.

LDAP / Active Directory access

Enable the ownCloud LDAP module via the web admin interface.

Run (with sudo/root permissions):

a2enmod ldap

apt-get install php5-ldap

service apache2 restart

Check your /etc/resolv.conf, it should contain your FQDN, e.g. “search domainexample.local”, and your DNS server(s).

In Windows AD configuration, create a group “ownCloudAccess” and place your users in there who should be able to use it.

Important: The current ownCloud seems to have problems with hierarchical AD user groups. So you should put your user names directly into this group and not another user group.

The AD connection configuration itself can be quite tricky, but you can compare your settings to the following screenshots.

As soon as you have finished LDAP configuration, you should see your AD users in the list.

Finish

Your ownCloud installation should work now.

If not, have a look at the log in the web interface (or via console).

For debugging purposes, you can also install sqlite3 to access the database.ownCloud is a quite simple and effective way to synchronize files and folders over LAN / internet, especially if you want to access them from mobile devices like Android phones / tablets, or via web interface.

The problem of ready-to-use cloud services like Dropbox, Skydrive etc. is, you never really know what the service provider does with your data, even if it is encrypted. ownCloud can run locally on your hardware and it is open source, so this way should be much safer.

This tutorial shows you how to install a Ubuntu VM on Hyper-V (or any other Hypervisor, or PC / server) in combination with LDAP / Active Directory.

Basic installation

First, create a new virtual computer in your Hyper-V environment, e.g. with 512 MB RAM or more. Ubuntu and ownCloud do not need too much resources. Choose a disk size according to how much space you need for your ownCloud storage.

Install the official Ubuntu ISO image, e.g. the server version of 12.04. It should work with default settings. Additionally, install SSH during the setup.

Log in and get the required packages via apt-get commands – see this site for details. Get ownCloud itself, also via apt-get – have a look here.

When the installation is finished, open http://[your-owncloud-server-ip]/owncloud in your browser and follow the wizard.

If you want to, you can do a first test now, e.g. use the ownCloud Windows client and try to connect with the Admin user.

SSL

If your ownCloud server is accessible from the internet, you should use SSL encryption to secure your data.

In the settings, also force ownCloud to use TLS.

Digicert has a good guide for creating the certificate request with your local Apache Server and how to integrate the final certificate.

LDAP / Active Directory access

Enable the ownCloud LDAP module via the web admin interface.

Run (with sudo/root permissions):

a2enmod ldap

apt-get install php5-ldap

service apache2 restart

Check your /etc/resolv.conf, it should contain your FQDN, e.g. “search domainexample.local”, and your DNS server(s).

In Windows AD configuration, create a group “ownCloudAccess” and place your users in there who should be able to use it.

Important: The current ownCloud seems to have problems with hierarchical AD user groups. So you should put your user names directly into this group and not another user group.

The AD connection configuration itself can be quite tricky, but you can compare your settings to the following screenshots.

As soon as you have finished LDAP configuration, you should see your AD users in the list.

Finish

Your ownCloud installation should work now.

If not, have a look at the log in the web interface (or via console).

For debugging purposes, you can also install sqlite3 to access the database.

First, create a new virtual machine in the environment of your choice, e.g. with a 50 GB HDD. In Hyper-V, you can leave all settings by default.

Download Ubuntu (Server Edition recommended).

Install Ubuntu on your new VM (“insert” the .iso File in the virtual drive, power on the VM and follow the setup instructions). Choose OpenSSH server to be enabled.

Log in (locally or remote).

Run “sudo -s” and enter your root password.

Then run:

apt-get update

apt-get upgrade

apt-get install php5

apt-get install phpmyadmin

apt-get install postfix

Note the password which you chose for phpMyAdmin and the root DB user.

Look for the TBG zip file download path.

wget [direct_path_to_zip_file]

(You can also download the file via your browser and then transfer it to your VM via WinSCP etc.)

cd /var/www

unzip [downloaded_zip_file]

Make sure index.php is now under /var/www/thebuggenie. If you got another subfolder “thebuggenie”, move the files 1 directory upwards.

chown -R www-data /var/www

Open http://[name_or_IP_of_your_VM]/phpmyadmin, log in with root credentials. Create a new database, e.g. “tbg” and a user, set a password and full permissions to your new DB.

Open http://[name_or_IP_of_your_VM/thebuggenie and fill in the DB data fields etc. The setup process is quite simple.

Even if the TBG setup does not show any errors, you might want mod_rewrite to be enabled:

a2enmod rewrite

Then we have to modify the default apache settings:

vi /etc/apache2/sites-enabled/000-default

Set every “AllowOverride” line to “All”, then restart Apache:

service apache2 restart

Bugfix for IE and TBG version 3.2.5.2: Open /var/www/core/templates/layout.php and add the following line, e.g. at line 8:

<meta http-equiv=”X-UA-Compatible” content=”IE=9″>

Now you can open the Web GUI of The Bug Genie and everything should work.

LDAP / AD integration

Open your TBG web interface with Admin credentials. Go to the configuration area -> Modules -> Install new modules. You should find the LDAP module there and enable and configure it. The screenshot shows the common settings for Active Directory.

Note:

Make sure you have your AD Domain Administrator credentials! You have to log in now with these credentials into TBG to have admin permissions.In this post I will describe how to install the free and powerful IT / development management tool The Bug Genie on Hyper-V 2008 R2 VM (or similar hypervisors) with guest OS Ubuntu 12.04 LTS and LDAP / Active Directory authentification.

First, create a new virtual machine in the environment of your choice, e.g. with a 50 GB HDD. In Hyper-V, you can leave all settings by default.

Download Ubuntu (Server Edition recommended).

Install Ubuntu on your new VM (“insert” the .iso File in the virtual drive, power on the VM and follow the setup instructions). Choose OpenSSH server to be enabled.

Log in (locally or remote).

Run “sudo -s” and enter your root password.

Then run:

apt-get update

apt-get upgrade

apt-get install php5

apt-get install phpmyadmin

apt-get install postfix

Note the password which you chose for phpMyAdmin and the root DB user.

Look for the TBG zip file download path.

wget [direct_path_to_zip_file]

(You can also download the file via your browser and then transfer it to your VM via WinSCP etc.)

cd /var/www

unzip [downloaded_zip_file]

Make sure index.php is now under /var/www/thebuggenie. If you got another subfolder “thebuggenie”, move the files 1 directory upwards.

chown -R www-data /var/www

Open http://[name_or_IP_of_your_VM]/phpmyadmin, log in with root credentials. Create a new database, e.g. “tbg” and a user, set a password and full permissions to your new DB.

Open http://[name_or_IP_of_your_VM/thebuggenie and fill in the DB data fields etc. The setup process is quite simple.

Even if the TBG setup does not show any errors, you might want mod_rewrite to be enabled:

a2enmod rewrite

Then we have to modify the default apache settings:

vi /etc/apache2/sites-enabled/000-default

Set every “AllowOverride” line to “All”, then restart Apache:

service apache2 restart

Bugfix for IE and TBG version 3.2.5.2: Open /var/www/core/templates/layout.php and add the following line, e.g. at line 8:

<meta http-equiv=”X-UA-Compatible” content=”IE=9″>

Now you can open the Web GUI of The Bug Genie and everything should work.

LDAP / AD integration

Open your TBG web interface with Admin credentials. Go to the configuration area -> Modules -> Install new modules. You should find the LDAP module there and enable and configure it. The screenshot shows the common settings for Active Directory.

Note:

Make sure you have your AD Domain Administrator credentials! You have to log in now with these credentials into TBG to have admin permissions.

If you want to be able to export to a network share which is created on another machine, you have to add the computer name of the Hyper-V host to the security settings of the other machine with the share (full access).

This should fix this error.

If not, try (for testing purposes) to add user SYSTEM, or everybody with full write access to the share.

In most cases, it is only the LAN adapter which has not the same name as on the previous host. So the only thing you need to do is to configure the new LAN adapter with the imported VM, or rename the LAN adapter before importing.

First I thought of maybe bad hv_* modules in the 11.10 version and put them on the blacklist, but that didn’t help.
The problem was, I had accidentally used the “old network adapter” in the Hyper-V manager instead of the default one.

With the default LAN adapter and the hv_* modules enabled, network speed was fine again.