Monday, 25 May 2015

net user cmd

View the current password & logon restrictions for the computer (plus machine role: Server/ Workstation).

View the current password & logon restrictions for the domain.

Set the number of minutes a user has before being forced to log off when the account expires or valid logon hours expire

Prevent forced logoff when user accounts expire

Set the minimum number of characters for a password.
The range is 0-14 characters; the default is 6 characters.

Set the maximum number of days that a password is valid.
The range is 1-49710; the default is 90 days.

Set passwords to never expire.

Set a minimum number of days that must pass before a user can change a password (default = 0)

Require that new passwords be different from 'x' number of previous passwords
The range for 'x' is 1-24

Synchoronise the user accounts database (PDC and BDC)

View user account details

Add a user account.
NET USER username {password | *} /ADD [options] [/DOMAIN]

Net user charvo Pasword1

Modify a user account.
NET USER [username [password | *] [options]] [/DOMAIN]

Net user charvo Password@123

Delete a username

Net user charvo /delete

Generate a random password:
NET USER administrator /random

Add a group
NET GROUP groupname /ADD [/COMMENT:"text"] [/DOMAIN]

Net user localgroup CBAdmins /add

Edit a group
NET GROUP [groupname [/COMMENT:"text"]] [/DOMAIN]
NET LOCALGROUP [groupname [/COMMENT:"text"]] [/DOMAIN]

Net user localgroup CBAdmins /comment:"Charvo Benjamin Group"

Delete a group

Net user localgroup CBAdmins /Delete

Add a user to a group
NET GROUP groupname username [...] /ADD [/DOMAIN]
NET LOCALGROUP groupname username [...] /ADD [/DOMAIN]

Net user localgroup Administrators charvo /add

Delete a user from a group
NET GROUP groupname username [...] /DELETE [/DOMAIN]
NET LOCALGROUP groupname username [...] /DELETE [/DOMAIN]

Net user localgroup Administrators charvo /Delete

LOCALGROUP will create/modify a group that is local to the computer rather than an Active Directory domain-wide group.


Create a group

C:\> NET LOCALGROUP spud /add

Add to guests

C:\> NET LOCALGROUP guests spud /add

Then remove

C:\> NET LOCALGROUP guests spud /delete

C:\> NET LOCALGROUP spud /delete

Thursday, 7 May 2015

Vmware Horizon View Server as a Desktop

VMware introduced support for Windows Server 2008 R2 virtual desktops in Horizon View 5.3.  This support wasn’t enabled out of the box.  It required an administrator to edit the View LDAP database to enable the feature and a special command-line only installation of the agent on the target desktop.
Horizon View 6 brought many new changes, including better support for Windows Server desktop.  The first patch set also added better support for this feature.
Why Use Windows Server 2008 R2 as a Desktop OS?
Historically, Microsoft licensing for virtual desktops has been a pain.  In the past, it required connecting endpoints to be covered under software assurance or users to be covered under expensive subscription-based licensing, and there were no service provider licensing options.
Although some of this appears to be changing with the latest per-user licensing SKUs that will be available on December 1st, 2014, the service provider side still hasn’t been fixed.
From a cost perspective, there are some benefits as well.  Windows Server Data Center licensing allows for unlimited Windows instances on licensed virtual hosts.  This can generate significant savings compared to VDA subscriptions.
Note: I am not an expert on Microsoft licensing, and the features and terms of Microsoft’s licensing can change frequently.  Please contact your Microsoft representative if you have any questions on licensing products for virtual desktop environments.
Enabling Windows Server 2008 R2 Desktop Support
Enabling Windows Server 2008 R2 desktop support have been streamlined from Horizon View 5.3, and manual edits to the LDAP database are no longer required.
The steps to enable this support are:
1. Log into the Horizon View Administrator console.
2. Go to View Configuration –> Global Settings
3. Click Edit.
4. Check the Enable Windows Server 2008 R2 Desktops checkbox and click OK.

Installing the Horizon View Agent
The process for installing the View Agent on Windows Server desktops has also been streamlined.  Installing the agent in View 5.3 required a command-line installation with a special switch to force the installer into desktop mode as the installer was geared for servers with the RDSH role.

Install security server vmware view

Horizon View provides a secure method for granting users access to their desktops from anywhere with an Internet connection on any device without needing a VPN connection.  Now that a desktop pool has been set up and desktops are provisioned, it’s time to set up that remote access.
The Security Server
The View Security Server is VMware’s method of addressing remote access.  This component of the Horizon View environment contains a subset of the Connection Server components, and it is designed to sit in a DMZ and act as a gateway for Horizon View Clients.  It’s essentially a reverse proxy for your View environment.
Each Security Server that is deployed needs a corresponding Connection Server, and they are paired during the installation process.  Because the Security Server is an optional component, each Connection Server is not required to have one, and a Connection Server cannot be paired to more than one Security Server.
Each Security Server also needs a static IP address.  If it is externally facing, it will need to have a publicly addressable static IP.  This IP address does not need to be configured on the server’s network card as both Static 1:1 NAT and PAT work with Horizon View.
Security Server Firewall Ports
In order to enable remote access, a few ports need to be opened on any firewalls that sit between the network where the Security Server has been deployed and the Internet.  If the server is deployed into a  DMZ, the firewall will also need to allow traffic between the Security Server and the Connection Server.
The rules that are required on the front-end, Internet-facing firewall are:
  • HTTP – TCP 80 In
  • HTTPS – TCP 443 In
  • HTTPS – TCP 8443 both directions (if Blast is used)
  • PCoIP – TCP 4172 In, UDP 4172 both directions
If you are deploying your Security Servers in a DMZ configuration with a back-end firewall, you need to configure your firewall to allow IPSEC traffic to the Connection Servers.  These rules depend on whether network address translation is used between the DMZ and Internal network.  For more information on the rules that need to be enabled, please see this VMware KB article.
The Security Server will also need to communicate with the Horizon View desktops.  The following ports will need to be opened to facilitate this:
  • PCoIP – TCP/UDP 4172 both directions
Note: If you’re using application-aware firewalls like Palo Alto Networks devices, make sure that any application protocols required by Horizon View aren’t blocked between the DMZ and Internal network.  Also, updates to the application signatures or the PCoIP protocol may impact users’ access to virtual desktops.
Configuring Horizon View for a Security Server
The Security Server installation will prompt for a Connection Server to be paired with and a pairing password during the install process.  This must be set up before the installation starts.  To set up the pairing password, take the following steps:
1. In View Administrator, go to View Configuration –> Servers
2. Click on the Connection Servers tab and select the Connection Server you want to pair with.

3. Click on More Commands and select “Specify Security Server Pairing Password.”

4. Specify your pairing password.  When you do this, you will also be able to configure how long that password will be valid for.  If the password is not entered in that time period, or if you encounter errors with the install that are not resolved before the timeout period expires, you will need to create a new password.

Note: Pairing passwords can time out or be invalidated by hitting the back button during the Security Server installation after the pairing password has been entered.  If this happens, the password will need to be recreated using the steps above.
Installing the View Security Server
Once the pairing password is set up, you can start the Security Server installation.
1. Double-click the installer to start the installation.
2. Accept the license agreement

3. The next screen gives you the option to change the installation directory by clicking the Change button.  For this installation, we’ll be installing to the default location, so click Next.

4. Select Security Server

5. Enter the hostname or IP address of the Connection Server the Security Server will be paired with.

6. Enter the pairing password.

7. In order for View Clients to properly connect to the Security Server, you need to configure the External URLs for the server.  The items that need to be configured are:
  • External URL – the fully-qualified public domain name and port such as
  • PCoIP External URL – the public IP address and port number.  If this server is behind a NAT, this should be the IP address that can be reached from the Internet.  Example:
  • Blast External URL – the fully-qualified public domain name and port used by VMware Blast such as

8. The View Installer will give you the option to automatically configure the Windows Firewall for View.  Click Next to allow the installer to set up the Windows Firewall.  If you do not want the installer to configure the firewall, you will need to configure these rules manually after installation.
Note: This also configures the IPSec Rules that are needed for secure communication between the Security Server and the Connection Server.

9. Click Install to finish the installation.
10. Click Finish to close the installer.
11. If you log back into View Administrator and go to View Configuration –> Servers –> Security Servers, you should see your newly added Security Server.

Building Master image prerequisites

Before You Begin, Understand Your Applications
Before we begin talking about how to configure the desktop base image and setting up the desktop pools, its very important to understand the applications that you will be deploying to your virtual desktops.  The types of applications and how they can be deployed will determine the types of desktop pools that can be used.
A few factors to keep in mind are:
  • Licensing – How are the applications licensed?  Are the licenses locked to the computer in some way, such as by computer name or MAC address?  Is a hardware key required? 
  • Hardware – Does the application require specific hardware in order to function, or does it have high resource requirements?  This is usually a consideration for high-end CAD or engineering applications that require a 3D card, but it could also apply to applications that need older hardware or access to a serial port.
  • User Profile and User Installed Applications – Are user profiles being centrally managed, or are they remaining local to the virtual desktops? Are users able to install their own applications?
  • Application Remoting – Can the applications be installed on a terminal server and presented to the users using an application remoting technology such as XenApp or Horizon Application Remoting?
Once you understand the applications that are being deployed to the virtual desktops, you can start planning your pools and creating your base images.
Supported Operating Systems
Horizon View only supports virtual desktops running Microsoft Windows.  The versions of Windows that are supported are:
  • Windows 8.1 Enterprise or Professional
  • Windows 8 Enterprise or Professional
  • Windows 7 Enterprise or Professional
  • Windows Vista Business or Enterprise SP2 (32-bit only)
  • Windows XP Professional SP3 (32-bit only)
[Note : With view 6.1 support end for window XP and vista]
Windows Server 2008 R2 is supported as a desktop operating system.  Configuring support for Server 2008 R2 desktops is easier in Horizon 6.0, and it only requires checking a single checkbox instead of editing the Horizon LDAP database.
Terminal Server sessions running on Windows Server 2008 R2 or newer are also supported, but I will cover those in another series.
For this part, we’re going to assume that we’re building a desktop running Windows 7 or Windows 8.1.  This will be more of a high-level overview of creating a desktop template for Horizon View, and I won’t be doing a step-by-step walkthrough of any of the steps for this section.
Configure the VM
Building a desktop VM isn’t much different than building a server VM.  The basic process is create the VM, configure the hardware, install the operating system, and then install your applications.  Although there are a few additional steps, building a desktop VM doesn’t deviate from this.
You should base the number of vCPUs and the amount of RAM assigned to your virtual desktops on the requirements for of the applications that you plan to run and fine tune based on user performance and resource utilization.
The recommended hardware for a virtual desktop is:
  • SCSI Controller – LSI SAS
  • Hard Disk – At least 40GB Thin Provisioned
  • Remove Floppy Drive, and disable parallel and serial ports in BIOS
  • Remove the CD-ROM drive if you do not have an alternative method for installing Windows.
Note: You cannot remove the CD-ROM drive until after Windows has been installed if you are installing from an ISO.

BIOS screen for disabling Serial and Parallel ports and floppy controller
You’ll notice that I didn’t put minimums for vCPUs and RAM.  Sizing these really depends on the requirements of your user’s applications.  I’ve had Windows 7 64-bit desktops deployed with as little as 1GB of RAM for general office workers up to 4GB of RAM for users running the Adobe Suite.
Install Windows
After you have created a VM and configured the VM’s settings, you need to install Windows.  Again, it’s not much different than installing Windows Server into a VM or installing a fresh copy of Windows onto physical hardware.  You can install Windows using the ISO of the disk or by using the Microsoft Deployment Toolkit and PXE boot to push down an image that you’ve already created.
When installing Windows for your desktop template, you’ll want to make sure that the default 100 MB system partition is not created.  This partition is used by Windows to store the files used for BItlocker.
Since Bitlocker is not supported on virtual machines by either Microsoft or VMware, there is no reason to create this partition.  This will require bypassing the installer and manually partitioning the boot drive.  The steps for doing this when installing from the DVD/ISO are:
1. Boot the computer to the installer
2. Press Shift-F10 to bring up the command prompt
3. Type DiskPart4. Type Select Disk 05. Type Create Partition Primary
6. Type Exit twice.
Once you’ve set up the partition, you can install Windows normally.  If you’re using something like the Microsoft Deployment Toolkit, you will need to configure your answer file to set up the proper hard drive partition configuration.
Install VMware Tools and Join the Template to a Domain
After you have installed Windows, you will need to install the VMware tools package.  The tools package is required to install the View Agent.  VMware Tools also includes the VMXNET3 driver, and your template will not have network access until this is installed.   The typical installation is generally all that you will need unless you’re using vShield Endpoint as part of your antivirus solution.
After you have installed VMware Tools and rebooted the template, you should join it to your Active Directory domain.  The template doesn’t need to be joined to a domain, but it makes it easier to manage and install software from network shares.
Install View Agent
After you have installed the VMware tools package and joined your computer to the domain, you will need to install the VMware View Agent.  The default install of the View Agent includes all of the features except for PCoIP Smartcard support.  The agent install will require a reboot after it is completed.
Installing Applications on the Template
After you install the View Agent, you can begin to install the applications that your users will need when they log into Horizon View.
With tools like Thinapp available to virtualize Windows applications or layering software like Unidesk or Cloud Volumes, it is not be necessary to create templates for all of the different application combinations.  You can create a base template with your common applications, such as your office suite, pdf reader, etc, and then either virtualize or layer your other applications on top of that.
“Finalizing” the Image
Once you have the applications installed, it is time to finalize the image to prepare it for Horizon View.  This step involves disabling unneeded services and making configuration settings changes to ensure a good user experience.
There are two ways to do this.  The first is to use the batch file provided by VMware in the Horizon View Optimization Guide for Windows 7 and Windows 8.  The other option is to use the VMware OS Optimization fling.
Before you shut the virtual machine down to snapshot it, verify that any services required for applications are enabled.  This includes the Windows Firewall service which is required for the View Agent to function properly.
Shutdown and Snapshot
After you have your applications installed, you need to shut down your desktop template and take a snapshot of it.  If you are using linked-clones, the linked-clone replica will be based on the snapshot you select.

Saturday, 2 May 2015

VDI and Microsoft Outlook Best Practice

VDI environments that we see at our clients are typically configured as non-persistent or floating pools of desktops.  That is, each user connects to a pool of identical desktops and grabs whatever desktop is available.  When the user logs off, any changes written to the VDI desktop are discarded and the desktop returns to a pristine state.  There are mechanisms and tools in place to make sure user data is retained at logoff.

So if user data is retained at logoff, why can’t we use Cached Exchange Mode in non-persistent VDI environments?

The OST file is equal in size to the user’s mailbox so storing a 15-30GB OST (not unusual at our clients) is not that practical from a performance or storage perspective.  If this data is being stored on the SAN, then you’re essentially doubling your Exchange storage (which may already be doubled or tripled if you’re using Exchange 2010 w/ DAGs).  In addition, the length of time it would take to download that file every time and the I/O impact that would cause makes it completely impractical.

OST files are not supported when stored on network shares, so redirecting the OST to a home directory is out.

Indexing of files on virtual desktops is typically disabled to reduce I/O demands.  This would prevent the use of Outlook Instant Search even if the OST was present.

Support for PST in Network Drives

One of the main challenges on VDI has always been around use of Outlook PST’s.Although PST’s are meant to be used as archiving or backup solutions , Smaller mail box size in large Organizations meant that People use PST all the time. I would not like to get into a discussion if one should use PST or not. As a VDI administrator ,  I might be against the use of PST’s but then decision varies from Organization to Organization and we have to live with it. PST’s are generally stored on Home drives ( Data Drive) that are presented to a User in a VDI session. Predominantly , Home Drives are carved out of NAS or on a more generic term “Network Drives”.  Until now , PST’s accessed over Network was not a supported Microsoft Configuration  which meant that you cannot log a case with Microsoft for any issues pertaining to use of PST’s on Network Drives.
Starting with Outlook 2010 , Microsoft has termed that “Network access of PST and OST as a Supported configuration” under specific conditions namely,
  • A high bandwidth/low latency network connection is used.
  • There is single client access per file (one Outlook client per .pst).
  • Windows Server 2008 R2 Remote Desktop Session Host (RDSH) and Virtual Desktop Infrastructure (VDI) are used.
This is a welcome change from a VDI Administrator perspective. There are always advantages and disadvantages of using PST on VDI and you would be the best person to judge if it’s suitable to your environment. Sometimes you don’t have a choice !
More details on Support for PST in Network Drives can be found in this Microsoft KB and would recommend reading the Planning Consideration White paper that can be found here.

VDI is a multitude of technologies that must work together in a premeditated way; and this we already know. However, couple weeks ago an interesting discussion in one of VMware’s internal forums sparkled my attention. The topic demonstrates clearly the level of attention and detail that a good VDI design should have. The central point of the question was about Microsoft Outlook configuration for VDI environments.

The practice recommends that PSTs be avoided in VDI, whenever possible. The reason for that is that the existence of PSTs in a given virtual desktop will tie that virtual desktop to a user, which is fine in the case of persistent desktops. What about if the desktop needs to be recomposed?
Well, a possible solution for that would be PST files in a Persistent Disk (UDD). If users are allowed to create PSTs in Persistent Disks, in a Persistent Desktop it’s then indispensable to carry out backups of these PSTs. The backup would have to be disk based and not agent based, since the user may leave Microsoft Outlook open inside the virtual machine. Of course there are way to solve that, like executing a automatic logoff or using a agent that support open files.
Let’s not forget that the main idea behind the creation of PST is due to the existence of the mailbox limit size imposed by administrators to save storage space on Exchange Servers. However, letting users create PST files they would be consuming the same amount of storage space from a same or different storage array. The Persistent Disk could be eventually located in a cheaper storage tier such as a NAS or SATA disks.
Anyway, seems like a good idea not to let users create PST on local disks, therefore increasing storage allocation for the Exchange Servers. In this way desktops could be part of floating pools and the users would have their independence from a single desktop that contains their PST.

The second problem to be solved are the OST files that are created when using Microsoft Outlook in Cached Mode. These cache files must be local and Microsoft does not support them in network shares. OST files are offline copies of server content that are locally indexed and synced with the server creating a high demand for disk traffic and IOPS. Additionally, every first use of Microsoft Outlook with Cached Mode enabled will force Outlook to sync server contents, causing a huge burst in network traffic and disk throughput and IOPS.
In a similar fashion to PSTs it is possible to accommodate OSTs in Persistent Disks, however the same constraints and issues apply. To keep up with the amount of IOPS a possible solution to consider is the use of SSDs, but the additional storage costs would not make sense from a TCO perspective.
Seems like it’s best to disable Cached Mode.

Disabling Cached Mode
Disabling Cached Mode we will be eliminating OST files, therefore getting rid of the persistent disk (UDD) requirement and also reducing network and storage bursts during the replication and indexing periods. However, now we have transferred the workload to Exchange Server.
Because OST files don’t exist anymore Microsoft Outlook will solely rely on being Online with the Exchange server for the user to send and receive and access mail, and this will put the IOPS burden on the Exchange Server, possibly impacting all users in the organisation should the server is not properly sized for the workload.
Another downside of Disabling Cached Mode is that Outlook Instant Search is unavailable if OSTs are disabled, and it will not index against Exchange Server. Since most users use advanced find to search for anything, the overall IO load could be much higher than it would have been if left on the virtual desktop. In summary, may be better to enable Cached Mode.
An interesting point raised during the conversations is that it is easier to manage Microsoft Exchange IOPS and network since it’s a single entity. Virtual Desktops are multiple and each individual desktop could have different requirements.users in the organisation should the server is not properly sized for the workload.