Are there any scripts or reports that would give me information on VMware VM’s with snapshots?
was pretty sure this was a straight forward one, so I jumped on the test network.
Solution: Get Snapshot Information
Connect to your vCenter and use the following commands.
[box]
Connect-viserver vCenter-Name
THEN AUTHENTICATEGet-VM | Get-Snapshot | Select-Object VM, Name, SizeGB, Created
[/box]
That was easy!
Get Snapshot Information : With RV Tools
You can also get the same information from RVTools, which if you don’t already use, do so!
Solution: PowerShell Delete Snapshots
You can delete all snapshots by simply piping the command above to Remove-Snapshot, But you will porbably want to do that on a VM by VM basis. Use the cfollowing command.
[box]
Get-VM VM-Name| Get-Snapshot | Remove-Snapshot
[/box]
Related Articles, References, Credits, or External Links
From setting up PKI environments, to migrating them, and a myriad of errors and problems in between, we have a lot of content on PNL referring to digital certificates and PKI. I’ve dealt with these technologies a lot over the past 20+ years and I’m always surprised how frightened of digital certificates people are. So in the space of a few minutes I’ll try and give you a basic understanding of what PKI is, how that relates to Digital certificates, then finish off with a few certificate ‘Golden rules‘.
Solution : Digital Certificates Explained
You will see I use the terms PKI environment, and Certificate Services and interchange those two things a lot, Certificate Services is the name of the Microsoft ‘Role” that provides Certificate Services. If you simply want to setup certificate services, then use the following link.
Before you understand certificates, you need to have a basic understanding of Public Keys, and Private Keys, how this key pair is used, and what Asymmetric Cryptography is (bear with me the maths might be mind boggling, but the concept is simple).
Public Key
The public key is shared openly and is used to encrypt messages or data. It is associated with a user (or entity) and can be freely distributed to anyone. Its primary function is to ensure confidentiality by allowing others to encrypt messages that only the owner of the corresponding private key can decrypt.
Private Key
The private key is kept secret and is known only to the owner. It is used for decrypting messages or data that have been encrypted with the corresponding public key. The private key is crucial for ensuring the authenticity and integrity of the data because only the person with the private key can decrypt and access the information.
Digital Certificates Explained: How These Keys are Used for Encryption
Encryption
1. Sender obtains the recipient’s public key and uses the recipient’s public key to encrypt the message.
2. Encrypted message is sent to the recipient.
Decryption
3. The recipient, (who possesses the corresponding private key), can then decrypt the message.
The strength of the security lies in the complexity of the key pair. Asymmetric cryptography is based on mathematical principles, making it computationally infeasible for someone to calculate the private key even if they have the corresponding public key. This makes it a secure method for tasks such as secure communication, digital signatures, and online transactions.
Digital Certificates Explained: Use of Keys and Certificates
Public Key Infrastructure (PKI) is a framework that manages digital keys and certificates. it requires the following:
Key Pair Generation: The process begins with the generation of a key pair (the public and private keys) for a user or entity. As shown above the public key is shared openly, and the private key is kept secret.
Certificate Authority (CA):A Certificate Authority is a trusted third party (public) or you own (private) system for authenticating digital certificates. in a PKI system.
The user’s public key is combined with other information (such as identity details and time stamps,) and then signed by the CA to create a digital certificate.
Digital Certificates: A digital certificate is a data structure that binds a public key to an individual, device, or service. It includes the public key, and information about the entity, the digital signature of the CA, and other metadata. So the digital certificate serves as a way for others to verify the authenticity of the associated public key and ultimately the identity of the entity.
Certificate Lifecycle: Certificates have a defined lifecycle, including issuance, and expiration. Note: They can also be revoked before expiration for example if compromised, or if the associated private key is lost.
Usage in Secure Communication
When parties want to communicate securely, they exchange their digital certificates. So just like the example above, the sender encrypts data with the recipient’s public key, which they get from the certificate that the receiver has published publicly, ensuring only the recipient, with the corresponding private key, can decrypt it.
Note: Digital signatures, created using the sender’s private key, can also be attached to messages to ensure authenticity and integrity. The recipient can verify the signature using the sender’s public key.
Digital Certificates Explained: Golden Rules Of Certificates
You must trust the CA that issued (authorised) the Certificate.
Every certificate has a CA that issued/approved it you NEED TO TRUST that CA, there are several trusted Certification Authorities that are built into your computer, and these are updated regularly with normal updates. this is why if you self-sign a certificate or build your own CA – then you may need to manually get people to trust your CA before they will be trusted. Also Certificate Authorities are hierarchical (they can have parent CAs) these form a CHAIN, and you need to be able to see that chain and trust ALL the CAs in that chain, (all the way back to the Root CA).
Above on my (current) site certificate you can see it was issued by a CA called RapidSSL, and that CA was authorised by a Root CA called Digicert Global Root G2. This means my certificate was signed by an intermediate CA (sometimes called and Sub CA).
The Certificate needs to be In Date
Certificates a have a date they were issued and a date when they will expire, If you are not at a point in time between these two dates, then you will not trust the certificate. (Note: this can happen if the internal clock/date on YOUR machine is incorrect).
Note: A Certificate that is in date can also be revoked. This is done by the CA, which publishes a list of certificates that have been revoked, (that your computer can check.)
The Common Name (CN) and/or Subject Alternative Name (SAN) needs to be correct.
In times gone by, the certificate CN had to be correct, but more modern browsers will require BOTHCommon Name and Subject Alternative Name to be correct. these are fields in the certificate that hold the name of the entity for example mine is www.petenetlive.com (that is the Common Name) This is the address (or FQDN) that is typed into the browser window to get to the site that presents this certificate.
Note: That means if you are putting a certificate on ‘something‘ be that a website, or a device, the NAME needs to be both correct, and resolvable by the person (or entity) that you want to trust it, e.g. if the common name was www.petes-site.com and you needed to type in https://www.petenetlive.com to get there, it would not be trusted (even if both names resolved to the correct IP address!)
You need to trust the ‘Algorithm‘ that signed the certificate.
This is a more recent development, I mentioned above that there’s some very complicated maths going on, as time moves on the mathematics needs to get more complicated, as computers get more powerful to maintain security. So older methods of signing have been depreciated, if a certificate is using technology that’s been depreciated it will also not be trusted.
Here’s an example of what happens when the signature algorithm is not trusted.
This is a pretty generic error. It basically means “I cant connect to what you are asking me to connect to, on TCP Port 443 (https)”.
Solution
Internet searching for this error is very frustrating, everyone who was posting this error was seeing it because, instead of putting the IP address or name in the box (that actually tells you to put in the IP address or name (see image above)). If you put in https://{Name or IP Address}, you will see this error. However this was NOT MY PROBLEM.
This is happening because there is no communication between you and the ESX/vCenter you are trying to connect to. The first thing you need to do is see if HTTPS is open. On the affected machine open a web browser and point it to the same target and make sure you see the web console of the ESX/vCenter server. If you can’t see this, check firewalls (and proxies) and make sure HTTPS is not getting blocked.
In my case I could see this but it still did not work! Then I was reminded we have had strange comms problems on this site before, which I have documented here. Sure enough, when I dropped the MTU on the server I was trying to connect from (which was over a site to site VPN tunnel). It started to work fine.
Related Articles, References, Credits, or External Links
Seen when trying to connect the Windows 8 mail client to Exchange 2010 (that is using a self signed certificate).
Error
Unable to connect. Ensure that the information you’ve entered is correct.
Solution
This is a right pain! My Exchange 2010 server is using a self signed certificate, and even though the Windows 8 client trusts my domain CA, and it has imported the cert that Exchange is using, it still would not work.
I Know the cert is OK, Outlook Web Access and Outlook work fine without reporting any certificate errors. I even put the CAFQDN in the Windows 8 hosts file in case it needed to see that (because I read that the problem is related to the client not being able to see the CA’s certificate revocation list).
The only way I found to cure this problem, and let me successfully connect to Exchange, is to remove the self signed certificate and use a purchased certificate.
Microsoft Exchange could not find a certificate that contains the domain name {name.domain.com} in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector SendConnector with a FQDN parameter of {name.domain.com}. If the connector’s FQDN is not specified, the computer’s FQDN is used. Verify the connector configuration and the installed certificates to make sure that there is a certificate with a domain name for that FQDN. If this certificate exists, run Enable-ExchangeCertificate -Services SMTP to make sure that the Microsoft Exchange Transport service has access to the certificate key.
In the error massage take note of {name.domain.com} this name is being used on one of your mail connectors, and the certificate on the Exchange server has a different name.
Solution
1. Launch Exchange Management Console > Organization Configuration > Hub Transport > Send Connectors > Right click your Send connector > Properties > Make sure the “Specify the FQDN this connector will provide…” section is the same as the name on your servers certificate.
2. Launch Exchange Management Console > Server Configuration > Hub Transport > Receive Connectors > Right click your Send connector > Properties > Make sure the “Specify the FQDN this connector will provide…” section is the same as the name on your servers certificate.
3. Start > run > services.msc {enter} > Restart the Microsoft Exchange Active Directory Topology Service > Select “Yes” to restart the other services.
Related Articles, References, Credits, or External Links
