vSphere 7 Lab - Nested deployment of VCSA 7 on VMware Workstation

In this post, I would talk about the changes noticed during the nested vSphere 7 Lab deployment and when tried to initially access the vCenter using WebClient.

For direct nested deployment where you are deploying the VCSA directly on VMware Workstation 13.x or later, its a three-step process but before we go into that, extract the VCSA7 iso file and locate the vcsa folder, there you will find the VCSA appliance OVA file.

• Right-click on vcsa open virtualization archive (ova) file and select open with VMware workstation or double click on this ova file => in subsequent screens follow the screen instruction and then provide the required IP, DNS, Gateway, FQDN etc and deploy the actual appliance
• Once the appliance is successfully deployed, set up its root password by accessing it through workstation console
• Now go to https://vcsa_fqdn_or_ip:5480, login with root and complete the rest of the configuration and deployment, vCenter PSC setup, create administrator password etc.

However, when I tried the same with VCSA 7 on the latest version on VMware Workstation 15.5.2, I was able to deploy and configure the appliance but was unable to access the vSphere WebClient.
I was able to access the vCenter Server Appliance Management Interface (VAMI) and complete the rest of the configuration however when tried to access the vSphere WebClient it simply failed.

Checked the status of the related services. found no issue however now I recall there was some error occurred during the VCSA appliance configuration however and there was no successfully completed message.

Then I thought to go with the standard lab deployment procedure, where we deploy VCSA on one of the already deployed ESXi hosts (double nested).

Once the deployment completed then I was able to access the vCenter Server Appliance Management Interface (VAMI) by going to https://vcsa_fqdn_or_ip:5480 and VCSA by going to https://vcsa_fqdn_or_ip:443 or just https://vcsa_fqdn_or_ip however, noticed that we no longer have flash-based WebClient client available (remember this url, https://fqdn_or_ip:9443/vsphere-client/). 

Now it is just HTML5 based WebClient.

As you can see, unlike vCenter 6.x there is no Flex-based vSphere WebClient option available.

One can access the vCenter Server by using the following url, https://vcsa_fqdn_or_ip/ui/

One more thing which I noticed that VMware Workstation 15.5.2 doesn't have ESXi 7 listed in supported OS list however I didn't see any issue when deployed it by selecting ESXi6.7. Hopefully, this would be available with the next update of the workstation.

Update: Tried to re-deploy the VCSA 7 appliance directly on VMware Workstation again and this time during post configuration deployment it got stuck at 70% with a page refresh error message however I waited for around 20 more minutes before hitting the browser refresh button which brought me to vCenter Server Appliance Management Interface (VAMI). Checked about the status of services and configuration and then tried to access it again using the https://vcsa_fqdn_or_ip and voila getting started page opened with an option to launch vSphere Client (HTML5) like shown in the first screenshot.

That's it for now...Thanks :)

AWS Glue Vs. Azure Data Factory : Similarities and Differences.

In today’s world emergence of PaaS services have made end user life easy in building, maintaining and managing infrastructure however selecting the one suitable for need is a tough and challenging task. We often tend to select hybrid cloud solution for our customers thus providing them the cost efficient solutions with cutting edge technologies.

The fundamental building block of any company is DATA  , without which no organization can think of survival. But to store and analyze this Data is the traditional approach of warehouse is not fit well because of many reasons. It could be increasing cost or infrastructure or over head of management ,but it does not fit well today.

The other alternative we have is Cloud , be it AWS / Azure /Google or any other. Each of these cloud offer different solutions to problems that we have. But fundamental Question remain same , which cloud to use and why.

Take Data analytics itself , For Running ETL jobs both AWS and Azure offer some solutions , but as architect we need to deeply understand the similarity and differences between two , before suggesting that to customer.

I am here highlighting the some fundamentals similarities and differences between two technologies  hoping that it might help the individuals who need to make solutions for customers .

Similar Features for two services 

Attribute	AWS Glue	Data Factory
Fully Managed, Server-less ETL engines	Yes	Yes
Data ingestion as both structured as well as unstructured data.	Yes	Yes
Auto generation of code	Yes	Yes
Underlying technology stack: Spark	Yes	Yes
Trigger type can be manual as well as automatic	Yes	Yes
Enable you to focus on building business logic and data transformation	Yes	Yes
Perform data cleaning, transformation and aggregation	Yes	Yes
Connects to data warehouses. Data lakes?	Yes, Support data to and from Redshift	Yes : Support  in and out from SQL DW
Transparent Pricing	Yes	Yes
Support SLAs	Yes	Yes
Ability for customers to add new data sources	Developers can write custom Scala or Python code and import custom libraries and Jar files into Glue ETL jobs to access data sources not natively supported by AWS Glue.	Yes

Differences between these two services

Attributes	AWS Glue	Data Factory
Main Focus of service	ETL, data catalog	ETL
Database replication	Full table; incremental via change data capture through AWS Database Migration Service (DMS)	Full table; incremental via custom SELECT query
SaaS sources	None	About 20, with several more in preview
Compliance, governance, and security certifications	HIPAA, GDPR	HIPAA, GDPR, ISO 27001,
Data sharing	Yes, within AWS	No
Vendor lock-in	AWS Glue is strongly tied to the AWS platform. Usage is billed monthly.	Month to month
Developer tools	Only python and Scala options are available.	REST API, .Net and Python SDKs, PowerShell CLI

Thanks for Reading .Your Suggestions and feedback's are welcome.

VMware vExpert 2020 Award Announced

I am very honored to be named a VMware vExpert again, this is my sixth time…..Congratulations to all those who made in the vExpert 2020 list.

VMware vExpert directory is available here.. https://vexpert.vmware.com/directory

And my vExpert profile can be found here.

Thank you VMware... :)

Amazon S3 Batch Operations related reads

Collection of related links about how to configure Amazon S3 Batch Operations,

https://docs.aws.amazon.com/AmazonS3/latest/dev/batch-ops.html

https://docs.aws.amazon.com/AmazonS3/latest/dev/batch-ops-iam-role-policies.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_permissions-to-switch.html

https://docs.aws.amazon.com/AmazonS3/latest/dev/batch-ops-basics.html

https://docs.amazonaws.cn/en_us/AmazonS3/latest/dev/batch-ops.html

https://aws.amazon.com/blogs/storage/encrypting-objects-with-amazon-s3-batch-operations/

https://aws.amazon.com/blogs/aws/new-amazon-s3-batch-operations/

Domain Trust Relationship issue on a recently migrated server

This is something you probably have seen where one is unable to login on a server due to domain trust relationship failure issue. Even I wrote a related post in past, can be found here, The-trust-relationship-between-this workstation.....

This week I came across this same issue again, where my team was able to temporarily fix it by removing and then re-joining the server to domain however after a few hours the same issue re-occurred again and this happened two-three times in a week (computer account reset didn't work for this machine).

While looking for the cause of the issue, the first thing checked was the dns and when tried to ping or nslookup dns server was not reachable.

Then connected to one of the other machines in the network to check the name resolution, and found the IP assigned to this machine was non-existent and when checked with the host-name, found there is another machine in the network with the same name but a different IP address.

When checked further, found this server was recently migrated from on-prem to Cloud and someone inadvertently started the on-prem servers (probably patching, etc) which caused the hostname conflict and as a result this DNS and trust relationship failure issue.

Once we figured out the cause and powered off the on-prem server then fixing the issue was as waiting for some time to update the server name in DNS or force it by re-registering the server with dns using following cmd in elevated mode(run cmd as administrator),

C:\ipconfig /registerdns 

It may take a few minutes to let you login using the hostname\user.

Update: 04/06/2020

While working on one related issues found some new PS commands added in our toolset to resolve this issue, related bold can be found here, https://theitbros.com/fix-trust-relationship-failed-without-domain-rejoining/


That's it... :)