If you want your IT infrastructure to go virtual, you need to know all the angles. However good your hypervisor may be, there’s always a catch. In this case, the potential of VMware ESXi doesn’t matter if the hardware is not up to date. For the highest performance possible, learn a few fine-tuning tricks!
Managing various operations in a virtualized environment usually calls for multiple tabs, each conforming to separate activities. Simplifying these operations and integrating them into a single GUI saves much time and effort to deal with other pressing matters. Windows Virtual Desktop can help you achieve just that from any host OS via Microsoft Azure.
Managing queries across various Microsoft 365 services can be somewhat challenging. The interaction across these applications in your cluster should be prioritized to ensure smooth workload. One handy tool to do that is Microsoft Graph Explorer, which exposes REST APIs and client libraries to access data on the aforementioned services.
Every admin knows a few tricks to find a short way when testing your VMs. Some of them are neat, and some aren’t, such as snapshots. Disk Mode in VMware ESXI allows you to replace this technology with a safe alternative!
In Part I of this article, we discussed how to handle multiple SSL sites sharing the same IP address and port bound to multiple SSL certificates in regards to SNI decryption and re-encryption with Kemp LoadMaster. We discussed briefly how to achieve this creatively. With Kemp LoadMaster, you will need to leverage sub-virtual services (SubVSs) in combination with content rules to handle this scenario. We also use SSL decryption and re-encryption in order to support the clients and servers with different TLS versions. Re-encryption is handled at the virtual service (VS) level, not at the SubVS level. Meaning you can only enter one SNI name for re-encryption with a shared VIP. So, in the case of two or more SSL sites sharing the same IP address, you would have only one that works.
As you all know by now, it really is time to say goodbye to TLS 1.0/1.1. You might be ready to only offer and support TLS 1.2. Perhaps you can even add TLS 1.3 as well. Being able and willing to block TLS 1.0/1.1 is a good thing completely. Well done.
In this blog post, we will talk about getting your Django project deployed to Amazon Web Services (AWS) platform. There are different ways you can do that with AWS: one is deployment to EC2 instance running Linux (you just connect to it over SSH and work with Linux server directly), and the other one is deployment to Elastic Beanstalk. The first scenario is close to simple project setup on a local Linux machine with some extra steps involved – for that you can refer to my previous posts which cover most of the steps involved. In this post, we will focus on Elastic Beanstalk deployment scenario, going through all the steps involved in this process when it is performed from Ubuntu.
We all know that connecting production VMs directly to the Internet via a public IP is a huge concern from a cybersecurity standpoint. Therefore, usually, all critical VMs don’t have public IPs, and they are managed either from a site-to-site VPN or a console VM that holds a public IP. In both cases, managing your Azure VMs is not easy since cybersecurity is a concern.
There are always several reasons to move on from your existing infrastructure. Some admins are pursuing recent versions of familiar products. Some, on the other hand, just want to get rid of the bugs they already learned to live with but would rather not. Others are attracted by promises to increase the performance of their environment. Finally, everybody wishes to go with the times and use the latest software. Whatever the reason, we all eventually come in terms with the necessity to upgrade the infrastructure to the most recent version.