Ubuntu Server 17.10 was randomly freezing / locking up after periods of time, even if left idle.  The solution for this VM was to change the type of network adapter assigned to the guest. By default, ESXi 6.5 will assign an adapter type of VMXNET 3 for a new guest VM. Switching it to E1000 in the VM settings seems to have resolved the problem.

If running Ubuntu Server you may need to perform the following steps to enable the new adapter after changing the adapter type for the VM:

First get a list of all adapters currently detected. Make note of the interface name (e.g., abc12)

ip l

Then enable the interface using the interface name recorded above

sudo ifconfig abc12 up

Then enable DHCP client for the interface

sudo dhclient abc12

You can now check if the system has obtained an IP address by using the following command:

ifconfig

To make this change permanent so that it persists with every reboot follow these steps:

Edit the following file:
/etc/network/interfaces

Then add the following lines. They may already be present referencing the old adapter name so you can simply update the name of the adapter.

auto abc12
iface abc12 inet dhcp

This is an example for downgrading from MongoDB version 3.6 to version 3.4 in Ubuntu 18.04 LTS, but it can be adapted for any combination of versions.

Remove old versions. Since this was done for a compatibility issue with UniFI Controller, the first step is optional

sudo apt-get remove unifi

sudo apt-get remove mongo*
sudo apt-get autoremove

Install MongoDB v3.4 Community Edition using the guide below. They also provide guides specific to other versions that you may need.
https://docs.mongodb.com/v3.4/tutorial/install-mongodb-on-ubuntu/

If you are doing this for UniFi Controller (optional), download latest controller package for Ubuntu
https://www.ubnt.com/download/unifi#

Install it (optional)

sudo dpkg -i unifi_sysvinit_all.deb

Fix any broken packages

apt --fix-broken install

This guide details how to change the certificate deployment level of a Windows Server 2012 R2 RD system from “Trusted” back to the default configuration of “Not Configured.”    The main problem is that the Windows GUI does not allow you to simply delete the trusted certificate and reset it back to the default “Not Configured” state for the deployment certificate level. Instead the GUI will only let you choose a different certificate (whether trusted or self signed). The steps below will get around this limitation and allow you to reset the deployment level.

First set of steps are to delete any existing Remote Desktop certificates and have Windows generate a new one automatically:

1. Launch mmc.exe on the 2012 R2 server
2. Choose File-Add/Remove Snap in
3. Add Certificates -> choose Computer account -> then Local computer. Click OK.
4. On left hand side browse to Remote Desktop folder -> Certificates folder
5. Delete all certificates
6. Launch services.msc
7. Restart Remote Desktop Configuration service
8. In Event Viewer – System, you should see a notification that a new self signed certificate was created
9. Go back to mmc.exe and at the top choose Action-Refresh.
10. Confirm new certificate is shown in Remote Desktop folder -> Certificates folder
11. Close mmc.exe. Choose No if it prompts to save.

The next set of steps are to change the deployment level:

There is one registry key that needs to be modified:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralPublishedResources\PublishedFarms\[NAME_OF_YOUR_FARM]\DeploymentSettings]

fHasCertificate – REG_DWORD set to a value of 0

Under this same key there is also a CertificateHash – REG_BINARY that contains thumbprint of the old certificate. It can probably be deleted but I have left it in place until it causes a problem.

There is a second key at the following location

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\

with a key titled CertExpiryTracking and under it a key with a title equal to the old certificate thumbprint with a LastPeriodLogged REG_DWORD decimal value of 15.  The entire CertExpiryTracking key can probably be deleted but I have left it in place until it causes a problem.

Now you will need to connect to the Windows Internal Database:

1. Download and install Microsoft SQL Server Management Studio (SSMS) v17 or higher
2. Launch SSMS
3. Connect to internal database using this server name:
   \\.\pipe\MICROSOFT##WID\tsql\query
4. Navigate to Databases -> RDCms -> and select rds.DeploymentSetting
5. Right click on it then choose Edit Top 200 Rows
6. Rename the following items:
   1. RedirectorCertificate – > RedirectorCertificate.bak
   2. PublishingCertificate -> PublishingCertificate.bak
   3. DeploymentCertificateHash -> DeploymentCertificateHash.bak
   4. WebAccessCertificate -> WebAccessCertificate.bak
7. Close SSMS
8. Close and reopen any Server Manager windows. Then go back and check that deployment certificate level is now showing as Not Configured.

Also if you were using a trusted certificate in IIS you may need to change the certificate for RDWeb by following these steps:

1. Launch IIS Manager
2. Right click Default Web Site, choose Edit Bindings
3. Select https, click Edit
4. Choose the appropriate SSL certificate in the dropdown list
5. Restart IIS

One scenario – booting a system using a USB Windows PE flash drive, the same flash drive then could not be read within Windows PE. This was because the PE image had no USB 3.0 drivers. The solution was to inject USB 3.0 drivers into the standard Windows 7 PE image.

1. Download the desired drivers
2. Extract the folder that contains the .cat, .inf, etc. files for the drivers (e.g., files can be extracted from a .exe using 7zip). Place them in a temporary folder (C:\x64)
3. Create a mount point folder on your local drive (e.g., C:\mount)
4. Open elevated command prompt
5. Get the name of the Windows PE system by pointing dism to the wim file (which could be on a portable media or your local drive). For example:

   dism /get-wiminfo /wimfile:c:\winpe_amd64\iso\sources\boot.wim

6. Mount it. In this example the name determined from previous step was “Microsoft Windows PE (x64)”

   dism /mount-wim /wimfile:c:\winpe_amd64\iso\sources\boot.wim /Name:"Microsoft Windows PE (x64)" /mountdir:c:\mount

7. Inject the drivers:

   dism /image:c:\mount /add-driver /driver:c:\x64 /Recurse

8. Unmount

   dism /unmount-wim /mountdir:c:\mount /commit

1. Download Windows 7 AIK ISO file
   https://www.microsoft.com/en-us/download/details.aspx?id=5753
2. Burn the ISO or extract it to a folder (e.g., using 7zip)
3. Run StartCD.exe
4. Choose the “Windows AIK Setup” option
5. When complete, navigate to Start->all programs -> Microsoft Windows AIK -> Deployment Tools Command Prompt
6. In the Deployment Tools Command Prompt window, issue the following commands.
   Note: if needing a 32-bit version of Windows PE, replace “amd64 with “x86”

   copype amd64 c:\WinPE_amd64
   copy c:\WinPE_amd64\winpe.wim c:\WinPE_amd64\iso\sources\boot.wim

7. Insert your flash drive
8. Launch diskpart (Start button-> then type diskpart)
9. Locate your flash drive with this commandlist disk
10. Select it, format it and make it bootable (in this case the flash drive was disk 1) using these commands:

    select disk 1
    clean
    create partition primary
    active
    format fs=ntfs quick label=WinPE_amd64
    assign
    exit

11. Determine what drive letter has been assigned to your flash drive
12. The last step is to copy files to flash drive (in this case drive letter of the flash drive was F:

    xcopy c:\WinPE_amd64\iso\*.* F:\ /

13. If you want to create an ISO to use later:

    oscdimg -n -bc:\winpe_amd64\etfsboot.com c:\winpe_amd64\iso c:\winpe.iso

Update 09-Feb-2025: added H200 method. The Support Files zip file was also updated for better EFI compatibility and to include the DOS version of sas2flsh.exe

Update 30-Oct-2019: clarified that BIOS flashing is optional, added an error that can be encountered on Step 12 and a warning that can be encountered on Step 15. The Support Files zip file was also updated to include a UEFI Shell Binary file.

Update 18-Aug-2019: added mouse initialization error, page parameter, Exit Code error and P20 BIOS and FW zip file. A duplicate file was also removed from the Support Files zip file.

This procedure is a combination of using the Legacy (DOS) + UEFI methods to flash an LSI SAS2008 chip based card Dell PERC H310 or H200 to an LSI 9211-8i in IT mode.

This method will flash both the firmware and also the BIOS of the card (optional) , which many guides omit.

1. Create a bootable USB flash drive using Rufus.
   1. Choose partition scheme: MBR for BIOS or UEFI
   2. Bootable disk using FreeDOS
2. Download the latest zip file from LSI/Broadcom that has the BIOS and firmware for the 9211 HBA card.  The two files needed for this guide can be downloaded from here: BIOS-Firmware (these are version P20 which are the latest available at this time).The files were sourced directly from Broadcom (https://www.broadcom.com/support/download-search?dk=sas+9211-8i)There are two files you need:
   1. Firmware (IT mode) file for 8i model, it will have file extension *.bin (typical file name 2118it.bin)
   2. BIOS file, it will have file extension *.rom (typical file name mptsas2.rom)
3. Place these two files on the root of the bootable flash drive
4. Also download and extract some support files to the root of this drive. These files are needed to prepare the card for updating. Download from here: Support Files.
5. Install the HBA card in the system
6.  Boot from the flash drive using Legacy/DOS mode (not UEFI mode). This will get you into FreeDOS.
7. Determine what the current SAS Address is of the card using one of the two methods below. Make a record of it because we will need to re-program this same address later.PERC H200:

   sas2flsh.exe -listall

   If after running the above command you get:  ERROR: Failed to initialize PAL. Exiting Program. Use Appendix A of this guide to boot into UEFI.  Then run the below command (UEFI only):

   sas2flash.efi -listall

   You should then be presented with a list of all detected adapters each with a number assigned to them. To get the address of the first card,  run the appropriate DOS or UEFI command:

   sas2flsh.exe -c 0 -list
   
   sas2flash.efi -c 0 -list

   
   PERC H310:

   megacli.exe -AdpAllInfo -aAll -page 20

   H310 Notes:

   1. the output of this command is several pages long. Use the parameter -page x where x is the number of lines to print per page
   2. If after running the above command you get Exit Code: 0x01 along with no device information, then no H310 adapter was found.
8. Now wipe the firmware of the card using this command:

   megarec.exe -writesbr 0 sbrempty.bin

   You may see an output that Chip is in FUSION mode.  When the step is complete, you should see: Success. 

9. The next step is the erase command:

   megarec.exe -cleanflash 0

   You should see the output Erasing Flash Chip (8 MB) with a % complete that increases over time.  When the step is complete, you should see: Completed: 100%.

   Note:

   1. When running the DOS commands above, you may receive the error below multiple times:
      DOS/32A warning (9004): mouse initialization failed
      This is typical and can be safely ignored.
10. Once complete, it is time to reboot into the UEFI shell using Appendix A of this guide.
11. At the UEFI shell, flash a Dell firmware using this command. Say Yes if it asks if you want to flash.

    sas2flash.efi -o -f 6GBPSAS.FW

    When you see: Firmware Flash Successful! the step is complete.

    Note:

    1. If you receive the following error after it says Firmware Download Successful, simply try the flash command again:
       Resetting Adapter … Adapter Reset Failed! Due to error remaining commands will not be executed. Unable to Process Commands. Exiting SAS2Flash.
       The error may appear a second time, but the second attempt should result in a successful flash output.
12. Next it is time to program the SAS address using the following command. Replace the X with the values you recorded earlier, but do not include the hyphens.

    sas2flash_p19.efi -o -sasadd XXXXXXXXXXXXXXXX

    You should see the output: SAS Address Successfully Programmed!

13. Reboot the system and boot back into the UEFI shell per Appendix A.
14. Now flash the firmware of the card to the latest 9211-8i firmware:

    sas2flash.efi -o -f 2118it.bin

    When you see: Firmware Flash Successful! the step is complete.

    Note:

    1. If you receive the message below then choose yes.
       NVDATA Product ID and Vendor ID do not match. Would you like to flash anyway [y/n]?
    2. Similar to the previous flashing step, you may get a Resetting Adapter … Adapter Reset Failed! Due to error remaining commands will not be executed. Unable to Process Commands. Exiting SAS2Flash. If the flash was successful on the first attempt, then this can be safely ignored.
15. Once complete, you have the option to flash the latest BIOS for the card. This is completely optional for a card running in IT mode since there are no disk management settings, however it may help with troubleshooting since it gives you diagnostic information about what devices are connected to the card during the boot process. If you skip this step then the card will not have a BIOS and your boot times should be reduced.

    sas2flash.efi -o -b mptsas2.rom

    Note:

    1. This is a legacy BIOS, so on some UEFI motherboards you may need to enable the option for Legacy mode for Storage Boot Option Control in the BIOS before you will see it during the boot process.
16. Once complete, reboot and you should now have a card running in IT mode. You can verify the results with the step above for checking the SAS address.  FW version should show as 20.00.07.00. If you chose not to flash the BIOS, x86-BIOS column will show as No Image.

Appendix A:

Steps to boot into UEFI shell:

1. Reboot the system and enter the BIOS.
2. Look for a boot override option that is described as either “UEFI” followed by the name of your flash drive or Launch UEFI Shell from filesystem device.   Select either one to continue.
3. At the UEFI command prompt, find out what device number has been assigned to your flash drive using this command

   map -b

4. Then type the device number followed by a colon symbol to get to the root of your flash drive in UEFI mode. For example, if you determine your flash drive is fs0 then you type:

   fs0:

5. This gets you to the root of the USB drive. From here, follow the appropriate steps in the main guide.

When trying to log in to Windows (in this case Windows 7 using a domain account) you may receive the following error

This particular situation occurred after a reboot following the installation of the latest Windows updates.

There are several suggestions out there to solve this problem, some more drastic than others. The most common root cause seems to be a problem with a corrupt registry. Specifically, several guides have you log in to the system with a separate local administrator account and then check and modify registry settings located at these locations:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\gpsvc
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SVCHOST

In this case there were no problems with these registry settings, so a different solution was needed.

It was discovered that the user account had both a ntuser.man file and a ntuser.dat file, located in the root of the affected users profile folder (C:\Users\username).  Depending on the account type, there should only be one or the other.  It is most common to have a .dat rather than a .man which was true for this specific user account. The ntuser.man file was also very small compared to the ntuser.dat file.

The solution was to log in with a separate local administrator account and then move/rename the ntuser.man file while leaving the ntuser.dat file untouched.

That allowed the user to log in again with no loss of data or Windows settings.

I could not find a reliable procedure for performing a factory reset / restore on these devices, so I have put one together. The official procedure from Asus did not work for me.

This has been tested specifically with the MeMo Pad 8 Model K011 (ME181C), but it should also work for the MeMo Pad 7 (ME176C).

Here are the steps:

1. Power off the tablet
2. Press and hold the volume up button. While holding it down, press and hold the power button.
3. Release both when you see the Asus logo appear.
4. The tablet should then boot into the Droidboot interface (shown below).
   
5. Scroll down and execute Recovery.
6. The tablet should then reboot into the recovery screen that has the robot tipped over with the message No Command (shown below).
   
7. Now press and hold the volume down key. While still holding it, press and release the volume up key.  You can now release the volume down key.
8. You should then be presented with the Android system recovery options that will allow you to do a factory reset.
9. It takes a while so be patient. Once done simply choose the option for Reboot system now.

After installing this update you may find that you are no longer ble to launch your Start Menu. When clicking on the Windows logo button, it is animated but the Start Menu doesn’t appear.

Try the following:

1. Press Control-Alt-Delete
2. Launch Task Manager
3. Click File-Run New Task
4. Type control panel and press enter
5. Choose User Accounts
6. Click the option for Make changes to my account in PC settings
7. If the window comes up but gets stuck with the gear icon, try right clicking on your Start Menu button a few times
8. When the settings window appears, Choose Sign-in options, located on the left
9. Find the option for Use my sign-in info to automatically finish setting up my device after an update or restart.  Having this option enabled seems to be the root cause of breaking the Start Menu
10. Disable this option then reboot.
    Note: an alternative way of safely rebooting without a working Start Menu is to use the command line. Start a new task cmd using Task Manager in similar fashion like steps 1-4 above. When the command window appears, type the command: shutdown -r and press enter.

Update 26-Feb-2020: See the updated version of this guide here: Upgrade to PHP 7 on CentOS 7 (or CentOS 6)

You may find that you need to upgrade PHP on your CentOS install in order to meet dependencies for an application. For example, a WordPress plugin:

Gmail SMTP plugin requires PHP 5.6 or higher. 
Please contact your web host to update your PHP version.

CentOS by nature maintains the same package version throughout the life cycle of its release, so for CentOS 7 you end up with PHP version 5.4 (e.g., 5.4.17).

The good news is that you can upgrade PHP using the IUS Community project repositories without breaking your CentOS install.

Here are the steps, which need to be run with sudo permissions:

1. yum --enablerepo=extras install epel-release

2. For CentOS 7: yum install https://centos7.iuscommunity.org/ius-release.rpm
   For CentOS 6: yum install https://centos6.iuscommunity.org/ius-release.rpm

3. yum install yum-plugin-replace

4. yum replace --replace-with php56u php

With the last step you may receive the following warning:

WARNING: Unable to resolve all providers ...
This may be normal depending on the package. Continue? [y/N]

For this procedure the warning is typical, so hit Yes

You will then be presented with a transaction summary as follows:

Transaction Summary ========================================
Install x Package(s) ....
Remove x Package(s) ... 
Is this ok [y/N]:

Verify that all of the packages being removed are being replaced with equivalent packages of the newer version. Then hit Yes.

Once complete, restart all services that use PHP or reboot the server.  Typically this is Apache, so to restart it issue the following command:

sudo apachectl restart