Unmap VMware | Updated Script

Update:

I created a new file that works with powershell 5.0 and powercli 6.5 r1. It seems that powercli 6.5 got rid of snapins so it broke my old script.  I have helped many of my clients reclaim TBs of space and I hope it helps you out as well.

The Question

Why does my SAN show I have used 1TB of space but VMware says I am using 500GBs?

So I have been working with a client for the last year and we started getting low on space.  So we started looking at finding Orphaned files and removing old VMs. This is the normal thing you would do on windows. Find the largest files you may not be using anymore and delete it or move it to an external hard drive.

We noticed the space was not going down on the SAN (in this case a EMC VNX2) but when we looked at VMware datastores it was going down. Why?!?!

The Fix

Way back in ESXi 5.0 (August 2011) VMware release a feature called Unmap.  At first I thought “Unmap? like unmap a network drive” but what it actually does is puts 0000 on all the free space in the given datastore.  This allows the storage to be released back to use on any other datastore.

Where can I use this?

  • This is only used on Thin Provisioned LUNs
  • Datastore in VMware using VMFS
  • Some kind of shared storage (SAN, NAS, etc.)

How can I use this?

So you want to free up some space, well there is a couple of ways to do this.

SSH

This is great if you are wanting to test on one host.

/vmfs/volumes # esxcli storage vmfs unmap -l datastore_name

PowerCLI

Selective Host and Datastore 

All Datastores on vCenter

What about Windows servers?

Some may be thinking that well this is all well and good but “what about windows servers they may have dead/grey space as well?” and you would be correct.  NTFS and VMFS do not clean up this dead space. So anytime you delete a file it is really not deleted it is just marked that it can be rewritten.

Powershell

Use powershell to reclaim that space

Sysinternals S-Delete – another windows based tool used for doing the same as above. Many people use this to zero out a drive of a VDI master image or of a VM that will sent to the cloud.

Conclusion

Okay, okay but what is the best way to get it ALL back!

  1. Run SDelete or the PS script on the all Windows VMs (this will create more load on your SAN! so do it after hours)
  2. Run PowerCLI Script on all datastores (this will also create more load on your SAN! but not as bad I found as SDelete)
  3. Sit back and watch your SAN reclaim space!

Real world example:

Reclaimed 20TBs so far on a 140TBs SAN and still going.

 

Remote Desktop connection defaulting to local machine

I ran into this the other day and needed to set the localhost name to the default login.  So you do the following but put the computer name in the domain field.

 

Q: How do I enforce the domain name in the logon dialog box?
Last modified: January 18, 2008

A: By default, the value for Domain/Computer in the logon dialog box is taken from the last logon that was used on the console. You can override this and force the correct domain name in the login box i Terminal Services Configuration:

Start – Administrative tools – Terminal Services Configuration – right-click RDP-tcp connection –
Properties – Logon Settings – select “Always use the following information”

Leave the User name and Password fields blank and enter the domain name you would like as the default in the Domain field.
Also make sure that you check the box for “Always prompt for password”.

 

Source: Remote Desktop connection defaulting to local machine

Unknown VMware Protection Policy

How to fix it:

Follow below steps from NetWorker server :
** “Also keep a bootstrap backup. So you should have an online and offline backup in case you need to restore. “. (Take a bootstrap backup.)
1. Make a copy of nsrdb: Open the <networker install directory>/res directory and copy the nsrdb to a safe location .
2. Stop all services
3. Connect to nsrdb using nsradmin using below command: Just Remove Quotes

nsradmin –d <path to nsrdb>

. type: NSR data protection policy

Print

Tip: You will see multiple policies printed. Select specific policy using below syntax:

. type: nsr data protection policy ; name: BadPolicy

Then delete the name of policy you want to remove using ‘delete’
Tip: When prompted hit ‘yes’
4. Start all services back

Found this on https://community.emc.com/thread/208326

Creation of UPS Printer Fails With Error “Client printer auto-creation failed”

Symptoms or Error

Creation of printers configured in Universal Print Server (UPS) policy fails when user logs on.

Background

When a user is member of a large number of security groups in Active Directory, it can cause to fail to create printers configured using a Universal Print Server policy.

Possible error messages

  • In the event viewer, the following message appears on the server/desktop where the user is logging on to:“Client printer auto-creation failed. The driver could not be installed. Possible reasons for the failure: The driver is not in the list of drivers on the server. The driver cannot be located. The driver has not been mapped. Client name: () Printer: (\\printserver\printername) Printer driver: ()”
  • Printers are not created on the user’s session.
  • The printer is created but the printer has the status “not configured”.

In all the cases, the user is unable to print to the printer and unable to connect to the UPS printer.


Solution

As shown in the following Universal Print Server architecture, the client and the server communicate over the HTTP protocol.

User-added image

As the user is a member of a large group of security groups in Active Directory, this can cause issues for the size of the request header the UPServer normally can handle. By default the maximum size is 8192 bytes (8K) for this cookie.
Complete one of the following options to resolve this issue.

Option 1

Limit the number of security groups that the user is member of in the Active Directory.

Option 2

When the UPS print server software is installed, there is an Apache webserver configured with it. This webserver is installed in the following location:
C:\Program Files\Citrix\XTE\

The conf folder contains a file named httpd.conf

  1. Add the following parameter LimitRequestFieldSize 65535  in the httpd.conf file before #Citrix_Begin or after #Citrix_EndThis changes the size of the request header to a maximum of 64K (similar to the maximum size for a Kerberos ticket).
  2. When the configuration file is changed, restart the UPS services (or restart the server completely) for the changes to take effect.
    Note: This option needs to be changed on all of the print servers where the UPServer software is installed.
    This also affects all users and no users or groups can be excluded.

Workaround

Complete the following steps as a workaround to fix the issue:

  1. Remove the user from several Active Directory security groups. The creation of the printer succeeds.
  2. Change the number of security group membership it was perceived that it could be a Kerberos issue MaxTokenSize registry key. However, after changing this to the maximum value of 65.535, the issue still exists.
  3. Change the name of the print server to the IP address of the print server. The creation of the printer succeeds.

Problem Cause

When a user is a member of a large number of security groups in the Active Directory it can fail to create printers configured using a Universal Print Server policy.


Additional Resources

Citrix Discussions – Citrix UPS Setup issues when adding network printer to host

The MaxTokenSize by default is 12,000 bytes. This has been the default value since Windows 2000 SP2 and still remains in Windows 7 and Windows 2008 R2. As the company grows, the groups within the organization also grows. If your Kerberos token becomes too big, your users will receive error messages during login; and applications that use Kerberos authentication potentially fail as well. This is why the default value is not a hard limit; the maximum recommended configuration is 65535 bytes or 64k.
Note: It is recommended that you do not set the MaxTokenSize greater than 65535 bytes or 64k. If you set the MaxTokenSize greater than 65535 bytes, applications using Kerberos authentication could potentially fail.
Refer to How to use Group Policy to add the MaxTokenSize registry entry to multiple computers for more information.