<==Charvo==> cloud age is upon Us

View the current password & logon restrictions for the computer (plus machine role: Server/ Workstation). NET ACCOUNTS View the current password & logon restrictions for the domain. NET ACCOUNTS /DOMAIN Set the number of minutes a user has before being forced to log off when the account expires or valid logon hours expire NET ACCOUNTS /FORCELOGOFF:minutes /DOMAIN Prevent forced logoff when user accounts expire NET ACCOUNTS /FORCELOGOFF:NO /DOMAIN Set the minimum number of characters for a password. NET ACCOUNTS /MINPWLEN:C /DOMAIN The range is 0-14 characters; the default is 6 characters. Set the maximum number of days that a password is valid. NET ACCOUNTS /MAXPWAGE:dd /DOMAIN The range is 1-49710; the default is 90 days. Set passwords to never expire. NET ACCOUNTS /MAXPWAGE:UNLIMITED /DOMAIN Set a minimum number of days that must pass before a user can change a password (default = 0) NET ACCOUNTS /MINPWAGE:dd /DOMAIN Require that new passwords be di

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 perspe

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. 

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, o

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 tha