HPE MSA Array Health Check

 HPE, MSA  No Responses »
Apr 292020
 
Screenshot of HPE MSA Storage Array Health Check

Are you having issues your HPE MSA SAN? Want to have more insight in to your storage array? Last week, HPE made available a new tool that allows you to check the health of your HPE MSA Storage Array!

While this tool was released to the public last week, rumor has it that this is the same tool that HPE uses internally when providing support to customers.

This tool is FREE to use!

I originally spotted this on the MSA Storage section of the HPE Community forums here: https://community.hpe.com/t5/msa-storage/new-hpe-tool-msa-health-check/td-p/7085594

HPE MSA Array Health Check Video

See below for a video discussing and demonstrating the HPE MSA health Check on an HPE MSA 2040 SAN array.

Accessing the MSA Health Check

The HPE MSA Health Check site can be found at https://msa.ext.hpe.com/MSALogUploader.aspx

The following HPE MSA Arrays are supported:

  • HPE P2000 G3 MSA Array
  • HPE MSA 1040/1050
  • HPE MSA 2040 and variants (MSA 2042)
  • HPE MSA 2050 and variants (MSA 2052)

How to use the MSA Health Check

Using the HPE MSA Health Check is easy!

  1. Log on to your MSA Array SMU (Storage Management Utility)
  2. On the bottom left of the UI, click on the following up-arrow and select save logs
    Save Logs on HPE MSA Array Screenshot
  3. Wait for the logs to generate.
  4. Download the logs to your computer
  5. Open the MSA Storage Array Health Check
    Screenshot of HPE MSA Storage Array Health Check
  6. Click on the “Upload MSA Log File (.zip)” button, and then select your log dump zip file
  7. Wait for the File to upload
    Screenshot of Upload status on HPE MSA Array Log File
  8. View your health report, and optionally download a PDF copy
    Screenshot of a HPE MSA Array Health Check Report

And that’s it!

Available Tests

When running a health check, the following tests and checks are made on the log files:

  • Background Scrub Setting
  • Compact Flash Events
  • Controller Firmware Version Mismatch
  • Controller Partner Firmware Update Setting
  • Default User Check
  • Drive Firmware Version Mismatch
  • Enclosure Firmware Version Mismatch
  • NonSecure Protocols
  • Notification Settings
  • Sparing Best Practices
  • Unhealthy Component Check
  • Volume Mapping

Conclusion

Even if your MSA array is healthy, I’d still recommend generating a log dump and loading it up in to the MSA Health Check. Any extra visibility, is good visibility!

NFS Root on Raspberry Pi 4

 NFS, Raspberry Pi, Raspberry Pi 4  15 Responses »
Apr 122020
 
Picture of Raspberry Pi 4 box and Raspberry Pi 4 board below box

If you’re worried about destroying your SD Cards, need some more space, or just want to learn something new, I’m going to show you how to use an NFS root for the Raspberry Pi 4.

When you use an NFS Root with your Raspberry Pi, it stores the entire root filesystem on a remote NFS export (think of it as a network filesystem share). This means you’ll have as much space as the NFS export, and you’ll probably see way faster performance since it’ll be running at 1Gb/sec instead of the speed of the SD Card.

This also protects your SD card, as the majority of the reading and writing is performed on the physical storage of the NFS export, instead of the SD card in the Pi which has limited reads and writes.

What you’ll need

To get started, you’ll need:

  • Raspberry Pi 4
  • Ubuntu or Raspbian for Raspberry Pi 4 Image
  • A small SD card for the Boot Partition (1-2GB)
  • SD card for the Raspberry Pi Linux image
  • Access to another Linux system (workstation, or a Raspberry Pi)

There are multiple ways to do this, but I’m providing instructions on the easiest way it was for me to do this with the resources I had immediately available.

Instructions

To boot your Raspberry Pi 4 from an NFS root, multiple steps are involved. Below you’ll find the summary, and further down you’ll find the full instructions. You can click on an item below to go directly to the section.

The process:

  1. Write the Linux image to an SD Card
  2. Create boot SD Card for NFS Root
  3. Prep the Linux install for NFS Root
  4. Create the NFS Export
  5. Copy the Linux install to the NFS Export
  6. Copy and Modify the boot SD Card to use NFS Root
  7. Boot using SD Card and test NFS Root

See below for the individual instructions for each step.

Write the Linux image to an SD Card

First, we need to write the SD Card Linux image to your SD card. You’ll need to know which device your SD card will appear to your computer. In my case it was /dev/sdb, make sure you verify the right device or you could damage your current Linux install.

  1. Download Ubuntu or Raspbian for Raspberry Pi.
  2. unzip or unxz depending on distribution to uncompress the image file.
  3. Write the SD card image to SD card.
    dd if=imagename.img of=/dev/sdb bs=4M

You now have an SD Card Linux install for your Raspberry Pi. We will later modify and then copy this to the NFS root and boot SD card.

Create boot SD Card for NFS Root

In this step, we’re going to create a bootable SD card that contains the Linux kernel and other needed files for the Raspberry Pi to boot.

This card will be installed in the Pi, load the kernel, and then kick off the boot process to load the NFS root.

I previously created a post to create a boot partition layout for a Raspberry Pi. Please follow those instructions to complete this step.

Later on in this guide, you’ll be copying the boot partition from the SD Card Linux image, on to this newly created boot SD Card for the NFS Root.

Prep the Linux install for NFS Root

There’s a few things we have to do to prep the Ubuntu or Raspbian Linux install to be usable as an NFS Root.

  1. Boot the Raspbian or Ubuntu SD Card you create in the first step on your Raspberry Pi.
  2. Complete the first boot procedures. Create your account, and complete the setup.
  3. Enable and confirm SSH is working so you can troubleshoot.
  4. Install the NFS client files using the following command:
    apt install nfs-common
  5. Open the /etc/network/interfaces file, and add the following line so that the Pi only get’s an IP once during boot:
    iface eth0 inet manual
  6. Modify your /etc/fstab entries to reflect the NFS root and the new boot SD card as per below.

For step 6, we need to modify the /etc/fstab entry for the root fs. It is different depending on whether you’re using Ubuntu or Raspbian.

For Raspbian, your /etc/fstab should look like this:

proc /proc proc defaults 0 0
LABEL=boot /boot vfat defaults 0 2
NFS-SERVER-IP:/nfs-export/PI-Raspbian / nfs defaults 0 0

For Ubuntu, your /etc/fstab should look like this:

LABEL=system-boot /boot/firmware vfat defaults 0 2
/dev/nfs / nfs defaults 0 0

After you do this, the Linux SD image may not boot again if directly installed in the Raspberry Pi, so make sure you’ve made the proper modifications before powering it down.

Create the NFS Export

In my case I used a Synology DS1813+ as an NFS server to host my Raspberry Pi NFS root images. But you can use any Linux server to host it.

If you’re using a synology disk station, create a shared folder, disable the recycling bin, leave everything else default. Head over to the “NFS Permissions” tab and create an ACL entry for your PI and workstations. You can also add a network segment for your entire network (ex. 192.168.0.0/24″) instead of specifying individual IPs.

Screenshot of Synology Create NFS rule for ACL
Create an NFS ACL Rule for Synology NFS Access

Once you create an entry, it’ll look like this. Note the “Mount path” in the lower part of the window.

Screenshot of NFS Shared Folder Permissions and Mount Point on Synology NAS
NFS Permissions and Mount Path for NFS Export

Now, if you’re using a standard Linux server the steps are different.

  1. Install the require NFS packages:
    apt install nfs-kernel-server
  2. Create a directory, we’ll call it “nfs-export” on your root fs on the server:
    mkdir /nfs-export/
  3. Then create a directory for the Raspberry Pi NFS Root:
    mkdir /nfs-export/PI-ImageName
  4. Now edit your /etc/exports file and add this line to the file to export the path:
    /nfs-export/PI-ImageName     IPorNetworkRange(rw,no_root_squash,async,insecure)
  5. Reload the NFS exports to take affect:
    exportfs -ra

Take note of the mount point and/or NFS export path, as this is the directory your Raspberry Pi will need to mount to access it’s NFS root. This is also the directory you will be copying your SD Card Linux install root FS to.

Copy the Linux install to the NFS Export

When you’re ready to copy your SD Card Linux install to your NFS Export, you’ll need to do the following. In my case I’ll be using an Ubuntu desktop computer to perform these steps.

When I insert the SD Card containing the Raspberry Pi Linux image, it appeared as /dev/sdb on my system. Please make sure you are using your proper device names to avoid using the wrong one to avoid writing or using the wrong disk.

Instructions to copy the root fs from the SD card to the NFS root export:

  1. Mount the root partition of the SD Card Linux install to a directory. In my case I used directory called “old”.
    mount /dev/sdb2 old/
  2. Mount the NFS Export for the NFS Root to a directory. In my case I used a directory called “nfs”.
    mount IPADDRESS:/nfs-export/PI-ImageName nfs/
  3. Use the rsync command to transfer the SD card Linux install to the NFS Root Export.
    rsync -avxHAXS --numeric-ids --info=progress2 --progress old/ nfs/
  4. Unmount the directories.
    umount old/
    umount nfs/

Once this is complete, your OS root is now copied to the NFS root.

Copy and Modify the boot SD Card to use NFS Root

First we have to copy the boot partition from the SD Card Linux install to the boot SD card, then we need to modify the contents of the new boot SD card.

Top copy the boot files, follow these instructions.

  1. Mount the boot partition of the SD Card Linux install to a directory. In my case I used directory called “old”.
    mount /dev/sdb1 old/
  2. Mount the new boot partition of the boot SD card to a new directory. In my case I used the directory called “new”.
    mount /dev/sdc1 new/
  3. Use the rsync command to transfer the SD card Linux install boot partition to the new boot SD card.
    rsync -avxHAXS --numeric-ids --info=progress2 --progress old/ new/
  4. Unmount the directories.
    umount old/
    umount new/

Now there are few steps we have to take to make to the boot SD card boot to an NFS Root.

We have to make a modification to the PI boot command. It is different depending on which Linux image (Ubuntu or Raspbian) you’re using.

First, insert the boot SD card, and mount it to a temporary directory.

mount /dev/sdc1 new/

If you’re running Ubuntu, your existing nobtcmd.txt should look like this:

dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait

We’ll modify and replace some text to make it look like this. Don’t forget to change the command to reflect your IP and directory:

dwc_otg.lpm_enable=0 console=tty1 root=/dev/nfs nfsroot=IPADDRESS:/nfs-export/PI-Ubuntu,tcp,rw ip=dhcp rootfstype=nfs elevator=deadline rootwait

For Raspbian, your existing cmdline.txt should look like this:

console=serial0,115200 console=tty1 root=PARTUUID=97709164-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

We’ll modify and replace some text to make it look like this. Don’t forget to change the command to reflect your IP and directory:

console=serial0,115200 console=tty1 root=/dev/nfs nfsroot=IPADDRESS:/nfs-export/PI-Raspbian,tcp rw vers=3 ip=dhcp rootfstype=nfs elevator=deadline rootwait

Once you make the modifications, save the file and unmount the SD card.

Your SD card is now ready to boot.

Boot using SD Card and test NFS Root

At this point, insert the boot SD Card in your Raspberry Pi and attempt to boot. All should be working now and it should boot and use the NFS root!

If you’re having issues, if the boot process stalls, or something doesn’t work right, look back and confirm you followed all the steps above properly.

You’re done!

You’re now complete and have a fully working NFS root for your Raspberry Pi. You’ll no longer worry about storage, have high speed access to it, and you’ll have some new skills!

And don’t forget to check out these Handy Tips, Tricks, and Commands for the Raspberry Pi 4!

VMware Horizon 7 Product Evaluation Extension – COVID 19

 End User Computing, Omnissa Horizon, VDI, VMware  No Responses »
Apr 072020
 
VMware Horizon View Icon

In response to COVID 19, VMware has extended their VMware Horizon 7 trial offering up to 90 days and includes 100 users. This includes both VMware Horizon 7 On-Premise, as well as VMware Cloud on AWS.

This is great if you’re planning or about to implement and deploy VMware Horizon 7.

In it’s simplest form, Horizon 7 allows an organization to virtualize their end user computing. No more computers, no more desktops, only Zero clients and software clients. Not only does this streamline the end user computing experience, but it enables a beautiful remote access solution as well.

And Horizon isn’t limited to VDI… You can install the VMware Horizon Agent on a Physical PC so you can use VDI technologies like Blast Extreme to remote in to physical desktops at your office. It makes the perfect remote access solution. Give it a try today with an evaluation license!

To get your evaluation license, please visit https://my.vmware.com/en/web/vmware/evalcenter?p=horizon-7.

Update: VMware Horizon 8 has been released. To get the latest evaluation, visit https://my.vmware.com/en/web/vmware/evalcenter?p=horizon-eval-8.

VMware Horizon Blank Screen

 End User Computing, Omnissa Horizon, Remote Access, VDI, VMware  19 Responses »
Apr 042020
 
VMware Horizon View Logo

In all my years assisting and providing support with VMware Horizon, one of the most common problems that customers report with their VDI implementations, is the VMware Horizon Blank Screen.

When a user is presented with a blank or black screen when using the VMware Horizon Client, the problem can be caused by a number of different things. In this post, I will address and provide solutions for some of the common issues that cause the VMware Horizon blank screen.

VMware Horizon Blank screen issue
VMware Horizon Blank screen issue

This troubleshooting guide applies to VMware Horizon 8, VMware Horizon 7, as well as earlier versions of VMware Horizon.

VMware Horizon Blank Screen Causes

There’s a number of different causes of a blank or black screen when connecting and establishing a VDI session to Horizon View. Click on the item below to jump to that section of the post:

Now that we have a list, let’s dive in to each of these individually. Some of these will require you to do your own research and will only guide you, while other sections will include the full fix for the issue.

VMware Tools and Horizon Agent Installation Order

When deploying the VMware Horizon View agent, you are required to install the agent, along with VMware tools in a specific order. Failing to do so can cause problems, including a blank screen screen.

The installation order:

  1. Install GPU/vGPU drivers (if needed)
  2. Install VMware Tools Agent
  3. Install the VMware Horizon Agent
  4. Install the VMware User Environment Manager Agent (if needed)
  5. Install the VMware App Volumes Agent (if needed)

It is important to also consider this when upgrading the agents as well. When upgrading VMware Tools, it is recommended to re-install the Horizon agent in versions up to and including Horizon 8 2103. As of Horizon 2106 and later, you no longer need to re-install the Horizon Agent when performing a VMware Tools upgrade.

For more information on the agent installation order for VMware Horizon, please visit: https://kb.vmware.com/s/article/2118048.

Network ports are blocked (Computer Firewall, Network Firewall)

For the VMware Horizon agent to function properly, ports must be accessible through your firewall, whether it’s the firewall on the VM guest, client computer, or network firewall.

The following ports are required for the VMware Horizon Agent when connecting directly to a View Connection Server.

DestinationNetwork ProtocolDestination PortDetails
Horizon Connection ServerTCP443Login, authentication, and connection to the VMware Connection Server.
Horizon AgentTCP22443Blast Extreme
UDP22443Blast Extreme
TCP4172PCoIP
UDP4172PCoIP
TCP3389RDP (Remote Desktop Protocol)
TCP9427Client Shared Drive redirection (CDR) and Multi-media redirection (MMR).
TCP32111USB Redirection (Optional), can be incorporated in to the Blast Extreme connection.
Network Ports Required for VMware Horizon View to View Connection Server

The following ports are required for the VMware Horizon Agent when connecting through a VMware Unified Access Gateway (UAG).

DestinationNetwork ProtocolDestination PortDetails
Unified Access GatewayTCP443Login, authentication, and connection to the Unified Access Gateway. This port/connection can also carry tunneled RDP, client drive redirection, and USB redirection traffic.
TCP4172PCoIP via PCoIP Secure Gateway
UDP4172PCoIP via PCoIP Secure Gateway
UDP443Optional for Login traffic. Blast Extreme will attempt a UDP login if there are issues establishing a TCP connection.
TCP8443Blast Extreme via Blast Secure Gateway (High Performance connection)
UDP8443Blast Extreme via Blast Secure Gateway (Adaptive performance connection)
TCP443Blast Extreme via UAG port sharing.
Network Ports Required for VMware Horizon View to VMware Unified Access Gateway (UAG)

You’ll notice the ports that are required for Blast Extreme and PCoIP. If these are not open you can experience a blank screen when connecting to the VMware Horizon VDI Guest VM.

For more information on VMware Horizon network ports, visit VMware’s Network Ports in VMware Horizon | VMware.

Certain types of IPS (Intrusion Prevention Service) can also intercept and block traffic. IPS may cause intermittent issues.

DNS Issues

While VMware Horizon View usually uses IP address for connectivity between the View Connection Server, guest VM, and client, I have seen times where DNS issues have stopped certain components from functioning properly.

It’s always a good idea to verify that DNS is functioning both internally and externally. DNS (forward and reverse) is required for VMware Horizon Linux guests VMs.

XDR, EDR, and AV Platform causing momentary blank screen at logon

When using an XDR (Extended Detection and Response), EDR (Endpoint Detection and Response), or special AV solution with non-persistent desktops, one may experience a momentary blank screen on user session logon. I have observed this with Sophos XDR as well as Cortex XDR, with blank screens varying from 10-30 seconds on user login.

Removal of the platform can reduce the momentary blank screen down to 1-5 seconds.

I highly recommend configuring and tweaking policies as much as possible to enhance and optimize your environment. There will always be a trade off of performance for security, and the decisions should be made by those in the organization who make cyber security related decisions.

Incorrectly configured Unified Access Gateway

A big offender when it comes to blank screens is an incorrectly configured VMWare Unified Access Gateway for VMware Horizon.

Sometimes, first-time UAG users will incorrectly configure the View Connection server and UAG.

When configuring a UAG, you must disable both “Blast Secure Gateway”, and “PCoIP Secure Gateway” on the View Connection Server, as the UAG will be handling this. See below.

Picture of the Secure Gateway settings on VMware Horizon View Connection Server when used with VMware UAG.
Secure Gateway Settings on View Connection Server when used with UAG

Another regular issue is when admins misconfigure the UAG itself. There are a number of key things that must be configured properly. These are the values that should be populated on the UAG under Horizon Settings.

Connection Server URLhttps://ConnectionServerIP:443
Connection Server URL Thumbprintsha1=SSLTHUMPRINT
(Thumbprint of the SSL certificate your View Connection Server is using)
PCOIP External URLUAG-EXTERNALIP:4172
Blast External URLUAG-InternetFQDN:443
Tunnel External URLUAG-InternetFQDN:443

You must also have a valid SSL certificate installed under “TLS Server Certificate Settings”. I’d recommend applying it to both the admin and internal interface. This is a certificate that must match the FQDN (internal and external) of your UAG appliance.

Once you’re good, you’re green!

Picture of the VMware UAG interface showing all green (functioning).
VMware Unified Access Gateway showing valid

You should always see green lights, all protocols should work, and the connections should run smooth. If not, troubleshoot.

GPU Driver Issue

When using a GPU with your VM for 3D graphics, make sure you adhere to the requirements of the GPU vendor, along with the VMware requirements.

Some vendors have display count, resolution, and other limits that when reached, cause Blast Extreme to fail.

An incorrectly installed driver can also cause issues. Make sure that there are no issues with the drivers in the “Device Manager”.

VMware documents regarding 3D rendering:

Blast Extreme log files can be found on the guest VM in the following directory.

C:\ProgramData\VMware\VMware Blast\

Looking at these log files, you can find information that may pertain to the H.264 or display driver issues that will assist in troubleshooting.

When using GPUs such as Nvidia GRID and AMD MxGPU, it is recommended to disable the VMware SVGA 3D Driver and adapter inside of Device Manager after you install the applicable GPU drivers.

NVIDIA vGPU Issues

You may be experiencing issues related to the NVIDIA vGPU platform, either inside of the VM guest, or on the VMware ESXi host.

Please check out my NVIDIA vGPU Troubleshooting Guide – How to troubleshoot vGPU on VMware for more information on how to troubleshoot, as well as a list of common issues experienced with VMware Horizon and NVIDIA vGPU.

VMware Tools

A corrupt VMware tools install, whether software or drivers can cause display issues. Make sure that the drivers (including the display driver) are installed and functioning properly.

It may be a good idea to completely uninstall VMware Tools and re-install.

If you’re experiencing display driver issues (such as a blank screen), before re-installing VMware Tools try forcibly removing the display driver.

  1. Open “Device Manager”
  2. Right click on the VMware Display adapter and open “Properties”
  3. On the “Driver” tab, select “Uninstall”
  4. Check the box for “Delete the driver software for this device”.

This will fully remove the VMware driver. Now re-install VMware Tools.

Horizon Agent

Often, re-installing the Horizon Agent can resolve issues. Always make sure that VMware Tools are installed first before installing the Horizon Agent.

Make sure that if you are running 64-bit Windows in the VM then you install and use the 64-bit Horizon Agent.

You may experience issues with the “VMware Horizon Indirect Display Driver”. Some users have reported an error on this driver and issues loading it, resulting in a blank screen. To do this, I’d recommend forcibly uninstalling the driver and re-installing the Horizon Agent.

To forcibly remove the “VMware Horizon Indirect Display Driver”:

  1. Open “Device Manager”
  2. Right click on the “VMware Horizon Indirect Display Driver” and open “Properties”
  3. On the “Driver” tab, select “Uninstall”
  4. Check the box for “Delete the driver software for this device”.

Now proceed to uninstall and reinstall the Horizon View Agent.

When running the Horizon Agent on Horizon for Linux, make sure that forward and reverse DNS entries exist, and that DNS is functioning on the network where the Linux VM resides.

Also, as a reminder, it is recommended that you re-install the Horizon agent in versions up to and including Horizon 8 2103 after upgrading VMware Tools. As of Horizon 8 2106, you no longer need to re-install the Horizon Agent when performing a VMware Tools upgrade.

Video Settings (Video Memory (VRAM), Resolution, Number of Displays)

When experiencing video display issues or blank screens on VMware Horizon View, these could be associated with the guest VM’s memory, video memory (VRAM), display resolution, and number of displays.

vSphere Video RAM (VRAM) configuration for VMware Horizon
vSphere Video RAM Configuration for VMware Horizon

If you do not have enough Video RAM (VRAM) allocated to the virtual machine and/or you have too many displays (multi-monitor), then you can experience the blank screen with Horizon.

Make sure you are adhering to the specifications put forth by VMware. Please see the following links for more information.

Master Image Resolution

While this isn’t likely to cause a blank screen issue (it can though), it’s always a good idea to set your image to a lower resolution before snapping or converting to a template for deployment.

It’s a lot easier for the VMs to start using lower resolution and VRAM (Video Memory) and then increase to what’s needed, instead of starting at a crazy high resolution and then getting adjusted down.

I consider it a good practice to reduce the graphics resolution before creating and deploying the image to the desktop pools.

Protocol

When troubleshooting blank screens with VMware Horizon, you need to try to identify whether it’s specific to the guest VM, or if it’s associated with the connection protocol you’re using (and the route it takes whether through a Connection Server, or UAG).

Always try different protocols to see if the issue is associated with all, or one. Then try establishing connections and find if it’s isolated direct to the Connection Server, or through the UAG.

If the issue is with a specific protocol, you can view the protocol log files. If the issue is with the UAG, you can troubleshoot the UAG.

Log files can be found in the following directory:

C:\ProgramData\VMware\

HTTPS Proxy and redirection issues

If you are connecting through a network that does passive and/or transparent HTTPS scanning or uses a proxy server, you may experience issues with inability to connect, or blank screens.

You’ll need to modify your firewall or proxy to allow the VMware connection and open the required ports for VMware Horizon and create an exception not to touch or manipulate the VMware Horizon related traffic.

Login banner or disclaimer (PCoIP)

I haven’t seen or heard of this one in some time, but when using VMware Horizon with PCoIP, sessions can fail or show a blank screen when the legal disclaimer login banner is used on the Windows instance (Windows 7, Windows 10, or Windows 11).

For more information on this issue, and how to resolve or workaround, visit https://kb.vmware.com/s/article/1016961.

Old version of VMware Horizon

It never stops surprising me how old some of the VMware Horizon View environments are that some businesses are running. VMware regularly updates, and releases new versions of VMware Horizon that resolve known issues and bugs in the software.

While it may be difficult, simply upgrading your VMware Horizon environment (VMware vSphere, View Connection Server, VMware Tools, VMware Horizon Agent) can often resolve many issues.

Blank Screen connecting to Physical PC running Horizon Agent

When you install the VMware Horizon Agent on a Physical PC, you may encounter issues with a blank screen.

This is usually caused by:

After troubleshooting these issues, you should be able to resolve the issue.

Conclusion

As you can see there are a number of different things that can cause Horizon View to show a blank screen on login. It’s always best to try to understand how the technology works, and establish where the failure points are.

Let me know if this helped you out, or if you find other reasons and feel I should add them to the list!

Free HPE iLO Advanced License

 HPE  2 Responses »
Apr 022020
 
HPE iLO Logo

In response to the COVID19 crises and to help customers and partners, HPE is providing a free iLO Advanced license for your HPE Servers.

These licenses are full licenses that are valid until January 1st, 2021. This means you’ll have the full Integrated Lights-Out product through the end of the 2020 year.

This was announced on the HPE Servers Facebook page, followed by a post on HPE’s blog!

You can watch my video below, or read on for more information!

How to get your free iLO Advanced license

To get your free license, head over to the link below.

https://www.hpe.com/us/en/resources/integrated-systems/ilo-advanced-trial.html

Free iLO Advanced License
Free iLO Advanced License

This link will take you to sign up for a HPE iLO Advanced trial license. After filling out the form, you’ll be able to download your iLO welcome letter, which includes your iLO key (that is valid through 2020), and instructions.

Free HPE iLO Advanced License key, instructions, and expiry date of January 1, 2021.

This is awesome, and will definitely help out a ton of IT administrators this year to remotely manage, monitor, and maintain their servers.

Thanks HPE!