I recently added a Juniper SSG5 from eBay to my home lab. When it arrived the config had not been erased as stated, but I've done this before on a Netscreen and the process is exactly the same for both Juniper Netscreen and SSG firewalls.
This process is quite simple once you get the timing right. It may take 2-3 attempts but the end result is a firewall device without any configuration at all and completley as factory defaults, including default username/password (netscreen/netscreen) and default management IP address (192.168.1.1).
I've been working with VMware View for a number of years, designing, implementing, fixing and upgrading it's various different versions released along the way.
VDI is an area of virtualisation I have grown to really enjoy. It represents more of a challenge than your normal server/DR virtualisation project can offer because there are so many more considerations. Not only that but the end result of your design and implementation is judged by the end users using this environment on a daily basis, if they're not happy, you will soon know about it.
So as a consultant travelling around and seeing various different companies and designing View environments based on more often than not quite lacking information about how they work, the most important take away I have had is ensuring the View environment itself and the infrastructure is configure correctly as a starting point. I will cover other aspects such as users and specific configurations in future posts, here I want to cover the core infrastructure best practices.
[[email protected] ~]# date
Sat May 10 12:01:05 UTC 2014
[[email protected] ~]# ls -alF /etc/localtime
lrwxrwxrwx. 1 root root 27 Mar 9 2013 /etc/localtime -> /usr/share/zoneinfo/Etc/UTC
[[email protected] ~]# rm /etc/localtime
rm: remove symbolic link `/etc/localtime'? y
I was recently in a situation where I needed to retain an existing vCenter Server (5.0) managing a number of clusters and build a new vCenter Server (5.5), then move a single cluster to this new vCenter (including with it a number of ESXi servers and VMs).
After which the ESXi servers would be upgraded and the VMs running on those hosts.
This is a pretty straightforward process if you are only using vCenter server to manage server virtual machines and can be done without any downtime to the VMs.
However if this vCenter Server is used to manage and provision your desktops in a Horizon View environment then it's unfortunately it's not that simple.
After installing VMware Horizon View HTML Access on the Connection Server you may see the following error message:
"Your VMware Horizon View server does not support web access"
After installing VMware Horizon View HTML Access on the Connection Server and enabling HTML Access for the required desktop pools you may see the following error message:
"This desktop does not support the requested display protocol"
In the first 2 parts we deployed and configured vCOPS foundation edition.
vCenter Operations Manager 5.8 (vCOPS) - Part 2 Configuring vCOPs and Introduction to vCOPS Foundation
Now in this 3rd instalment we are going to upgrade from vCOPS foundation to standard edition.
Standard edition still only requires the virtual appliance (vApp) and is simply upgraded by assigning a license key and the vCOPS edition changes on fly.
In Part 1 we deployed the vCOPS vApp which contains our 2 VMs; the Analytics VM and the UI VM.
Now that the 2 VMs within the vApp are powered on, we are ready to configure vCOPS.
Firstly what is vCenter Operations Manager, also known as vCOPS? VMware describe it as follows..
"vCenter Operations Manager (vCOPS) automates operations management using patented analytics and an integrated approach to performance, capacity and configuration management."
I'm my words.. vCOPS provides integrated, intelligent monitoring of the entire virtual (or cloud) environment. This could be simply vSphere (vCenter and ESXi) and it's virtual machines, or it could extend to capacity, networking devices, storage. Perhaps you would like to monitor physical servers and the operating system within both virtual and physical machines including checking for compliance. vCOPS can do all of this.
Welcome to the final part 4 of my vCenter Orchestrator series! Don't worry I'm sure I'll do more vCO blogs in addition to this series, it's product with a huge amount of possibilities and as I gain experience with it I'll try and share that with you!
We have now deployed vCO as a virtual appliance, configured it and ran a couple of workflows to see how it works and integrates with vSphere Web Client.
We're going to take the integration with vSphere Web Client just a little bit further. In the previous part 3, you saw a vCenter Orchestrator context menu, from which we ran a workflow.
It's possible modify that context menu and add additional workflows, both existing and new to that context menu.
And you can choose whether thats the context menu at the Datacenter level, cluster, folder, VM and so on.
Share this blog post on social media:Tweet
All advice, installation/configuration how to guides, troubleshooting and other information on this website are provided as-is with no warranty or guarantee. Whilst the information provided is correct to the best of my knowledge, I am not reponsible for any issues that may arise using this information, and you do so at your own risk. As always before performing anything; check, double check, test and always ensure you have a backup.