Wednesday, 31 December 2014

user profile conflict in c drive and d drive or user profile is not creating in d drive


When you login to your view desktop, you see a Error message "The Group Policy Client Service failed the logon. Access is denied." 

This issue happens when user profile is already available in parent image or master image.

when i login to view desktop from my vpshere console via local administrator, i see my profile  is available in c drive.


when i look for my sid in personality i also see my profile is created in persistent disk.

As some Microsoft administrators would know, certain SIDs are always mapped to certain accounts and the following are these mappings:

S-1-5-18
Local System, a service account that is used by the operating system.

S-1-5-19
NT Authority, Local Service

S-1-5-20
NT Authority, Network Service

S-1-5-21-1244467668-13315860-265647015239-500
S-1-5-domain-500 - A user account for the system administrator. By default, it is the only user account that is given full control over the system.

Aside from the persistent mappings above, there were also additional additional SIDs included in the folder and these were the ones that I wanted to determine what accounts they were mapped to:

S-1-5-21-3827024097-3178010264-148050-1020
S-1-5-21-3827024097-3178010264-148050-1034
S-1-5-21-3827024097-3178010264-148050-1821
S-1-5-21-3827024097-3178010264-148050-4332
S-1-5-21-3827024097-3178010264-148050-4335

So now i want to delete my user profile, i go to system properties, and click on settings in User Profile


Now i can see my profile, i select my profile and delete it



Once my profile is deleted i logoff my desktop and try to login from my Credentials

Now i see that my profile is created as a TEMP profile.


when i check in users folder TEMP profile is created.



so make changes in complete system, i will login to base image and follow the same staep to delete user profile delete i did in vdi dektop.

Go to system Properties
open settings of User Profile

Now i can see my profile, i select my profile and delete it



Once my profile is deleted i logoff my desktop and try to login from my Credentials

Now open Regedit



Go to this path
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList



Search My SID, user details will be available in ProfileImagePath. here you can see user profile in c drive. delete respective user profile which having issues

Click Yes



when all user profile is deleted which was having issues, no need to delete local admin profile.


Power Off base image and take Snapshot


Recompose desktop which having issues


Once the recompose operation completed, Login via local administrator to vdi desktop

Navigate to d:/personality/profiles



Delete the problematic user’s SID reference


Navigate to d:/personality.bak/profiles


Delete the problematic user’s SID reference


To my surprise, I noticed the same message I received earlier:

You have been logged on with a temporary profile.

You cannot access your files and files created in this profile will be deleted when you log off. To fix this, log off and try logging on later. Please see the event log for details or contact your system administrator.


With that being said, what I did notice differently this time was that the TEMP profile that was created was now stored on the persistent D drive:



So I proceeded to log off of the virtual desktop, deleted the TEMP profile and performed a refresh of the virtual desktop


I went ahead and logged back onto the virtual desktop after the refresh completed, and noticed that the profile was now successfully created on the D drive:

if having issue User profile not redirecting to persistent disk till this step. you desktop profile start redirecting.

If desktop  already have a user profile in persistent disk and its conflicting , you need to also perform below given steps
since your profile was available in persistent disk and  now there is no link to your exsisting profile
 A new profile will be created in persistent disk like username.domain.com.
Now u see two user file in persistent disk one is your old user profile(username) and one is your new profile(username.domain.com)
Open regedit


Go to this path
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
Find your newly created user profile sid


Double click on “profileImagePath” 


Change “username.domain.com” to “username” since your old profile is created with username only, we will point it to old one.


Enter ok



Now it is point to your old user profile
Just logoff vdi desktop and login back, you will login to your old profile desktop.

Tuesday, 30 December 2014

System Administrator command line shortcuts to Launch MMCs

Shortcuts to microsoft management consoles & control panel snap-ins.

Simply get to a run command (Start>Run)
or a  command prompt (Start>Run>CMD [enter])


Admin Applet Command
AD Domains and Trusts domain.msc
Active Directory Management admgmt.msc
AD Sites and Services dssite.msc
AD Users and Computers dsa.msc
ADSI Edit adsiedit.msc
Authorization manager azman.msc
Certification Authority Management certsrv.msc
Certificate Templates certtmpl.msc
Cluster Administrator cluadmin.exe
Computer Management compmgmt.msc
Component Services comexp.msc
Configure Your Server cys.exe
Device Manager devmgmt.msc
DHCP Management dhcpmgmt.msc
Disk Defragmenter dfrg.msc
Disk Manager diskmgmt.msc
Distributed File System dfsgui.msc
DNS Management dnsmgmt.msc
Event Viewer eventvwr.msc
Indexing Service Management ciadv.msc
IP Address Manage ipaddrmgmt.msc
Licensing Manager llsmgr.exe
Local Certificates Management certmgr.msc
Local Group Policy Editor gpedit.msc
Local Security Settings Manager secpol.msc
Local Users and Groups Manager lusrmgr.msc
Network Load balancing nlbmgr.exe
Performance Monitor perfmon.msc
PKI Viewer pkiview.msc
Public Key Management pkmgmt.msc
Quality of Service Control Management acssnap.msc
Remote Desktop tsmmc.msc
Remote Storage Administration rsadmin.msc
Removable Storage ntmsmgr.msc
Removable Storage Operator Requests ntmsoprq.msc
Routing and Remote Access Manager rrasmgmt.msc
Resultant Set of Policy rsop.msc
Schema management schmmgmt.msc
Services Management services.msc
Shared Folders fsmgmt.msc
SID Security Migration sidwalk.msc
Telephony Management tapimgmt.msc
Terminal Server Configuration tscc.msc
Terminal Server Licensing licmgr.exe
Terminal Server Manager tsadmin.exe
Teminal Services RDP MSTSC
Teminal Services RDP to Console mstsc /v:[server] /console
UDDI Services Management uddi.msc
Windows Mangement Instumentation wmimgmt.msc
WINS Server manager winsmgmt.msc

Wednesday, 24 December 2014

Horizon Toolbox-View Auditing Tool

The Horizon Toolbox is a new web portal that serves as an extension to Horizon View Administrator. It has the following functions:
Auditing
  • Sessions:  Shows historical concurrent session trend for last 2 days, last week and last month. Shows current virtual desktop connections by desktop pools, and shows virtual application connections by RDS (Remote Desktop Service) Farms.
  • Usage:  Shows accumulated use time of users for last 2 days, last week and last month.  Shows all connections (user name, pool/farm name, machine name, connection time, disconnection time) for the past 2 days, last week, and last month.
  • Snapshots:   Shows parent virtual machines of linked clone desktop pools and descendant snapshots in a tree view. The snapshots not in use by linked clone pools are marked in grey, so that the View administrator can remove the snapshots not in use.
  • Clients:  Shows statistics for operation systems and versions of View clients in different types of view styles.
Remote Assistance
Remote Assistance provides the capability for the administrator or IT helpdesk to remotely view and/or control an end-user’s desktop in the Horizon View environment.  (This is also called session shadowing.)
Device Access Policy
Device Access Policy provides a whitelist to control devices that can access Horizon View.

System Requirements

System Requirements for Horizon View Connection Server
  • Horizon 6.0 or above
If you want to use the "Sessions" or "Usage" functions, you must configure an event database from View Administrator.
System Requirements for Guest Operation Systems
If you want to use the "remote assistance" or "device access policy" functions, your guest operation system must have Microsoft .net framework 2.0 or above. For Windows 7 or Windows 8, they include .net framework as an OS component by default.

Instructions

Prerequisite
"JRE_HOME" environment variable with JRE 7 or later.
For example, set "JRE_HOME" to be "C:\Program Files\VMware\VMware View\Server\jre\"
Installation Guide
  1. Unzip "HorizonToolbox1.5.zip" to any folder, for example, the target folder is "C:/HorizonToolbox1.5/".
  2. Open "Command Prompt" and go to "bin" folder in your target folder, for example, "cd C:/HorizonToolbox1.5/bin"
  3. Execute "service.bat install", you should see "The service 'Tomcat8' has been installed."
Trouble shoot: If you see an error message "JRE_HOME not found", please make sure that the environment variable "JRE_HOME" takes effect.
Startup
  1. Double click "tomcat8w.exe", you will see a GUI
  2. Switch to "Java" tab, and adjust the "Maximum memory pool" to "512" or bigger, Click "Apply"
  3. Switch to "General" tab, click "Start"
You can close this GUI after your service is started.
Usage Guide
Login with IE9/10, Chrome, Firefox or Safari. IE8 is not supported. The default port is 18443.
https://[YourServer]:18443/toolbox/
Tip: If you can't access the above URL, please edit your fire wall inbound rule for allowing 18443 port.
You can login with either "Read only administrators" or "Administrators". "Read only administrators" can't enable CEIP, can't setup device access policy.
check out instruction
Download Horizon Toolbox

VMware View 2 Factor Authentication Radius

 VMware added support for RADIUS, allowing you to integrate with third-party multi-factor authentication products. SecureAuth IdP takes advantage of this RADIUS support by enabling Administrator-free distribution of 2-Factor Authentication to VMware View using one of our OATH mobile OTP applications:
  • iOS
  • Android
  • Windows Phone
  • BlackBerry
  • Windows Desktop
  • Macintosh Desktop
  • Browser OTP Application
  • OATH-Compliant Hardware Tokens

RADIUS has been around since the early 1990s, and many organizations offer two-factor authentication with RADIUS. SecureAuth’s low-friction user enrollment and self-provisioning/de-provisioning of OTP devices offers a unique and valuable mechanism for deploying this multi-factor authentication while removing the burden from the administrators managing the solution.

Unlike typical hardware tokens which require the administrator to follow a tedious process to associate each token serial number to a user account, usually by importing token serial numbers and manually matching these serial numbers to an account; SecureAuth provides a simple user self-registration process. Users may download the mobile OTP application from the SecureAuth mobile app store (or the appropriate vendor mobile application store) and self-register their mobile OTP application using any combination of our 20 authentication methods.

Once configured, users login to VMware View using a simple 2-factor process:
Enter their username and password

Retrieve OTP from mobile application

Enter OTP from Mobile OTP app/token

The administration configuration is also easy and straight forward.
1) On the VMware View Connection Server, select the Authentication page, and create a new RADIUS Authenticator
2) Configure the authenticator to your SecureAuth IdP RADIUS server by configuring the address, ports, protocol, and shared secret. If desired, configure a secondary authentication server for fault tolerance

3) In the SecureAuth Radius server configuration “radius.config” file, specify the following components:
    • URL Path to the SecureAuth Moble OTP Registration and Validation Realm
    • Shared Secret Configured on the VMware View Connection
    • RADIUS Authentication and Accounting Ports
    • Authorized RADIUS Clients and Allowed Methods — for VMware View, configure “PASSWORD_AND_OTP” to force a multi-factor authentication 


4) Configure The SecureAuth mobile OTP Registration Realm (998 be default) for the desired single or multi-factor methods to validate users when they register their Mobile OTP Token applications:
1.  SMS OTP
2.  Telephony OTP
3.  Email OTP
4.  Static PIN
5.  KBA/KBQ (Knowledge Based Questions and answers)
6.  Yubikey (USB)
7.  X.509 Native
8.  X.509 Java
9.  NFC Prox Card
10. CAC/PIV Card
11. Mobile OATH Token (TOTP)
12. Browser OATH Token (TOTP)
13. Windows Desktop OATH Token (TOTP)
14. Third-Party OATH token (TOTP)
15. PUSH Notification
16. Help Desk
17. Social IDs (Google, Facebook, Twitter, LinkedIn)
18. Federated IDs (SAML, WS-Fed, OpenID)
19. Device Fingerprinting
20. Password

VMware View Basic Concepts

“VMware Horizon™  (with View) delivers virtualized and remote desktops and applications through a single platform and supports end users with access to all of their Windows and online resources through one unified workspace.”
we will be discussing linked clones!!
So, what is a linked clone?
It’s the weekend and you're out at a dinner party with several new friends. The conversation goes around the table from person to person and everyone talks about who they are and what they do for a living. The conversation gets around to you and you say, “I'm a VMware View Administrator”. If your friends are like mine, you will get blank, questioning stares in return. As a VMware View Administrator, what do you tell people what you do when they ask and how do you explain it?
I tell them I'm a tree tender.
To most people, the concept of virtualization is foreign, but a simple explanation is normally enough to understand what a virtual machine is and provide a basic idea of how it works. But what about a linked clone? This is where we use our tree analogy.
Simplifying things, if you were to describe a tree to someone, how would you do it?
A tree has a central core or trunk, several leaf-covered branches coming off at the top, and at the base in the ground it has roots. A linked clone can be thought of in a similar way.

The Tree Trunk

This can be known as the template, golden image, or base image. It is a virtual machine (VM) that is installed with all of the appropriate Windows updates, applications and patches that your users require. This is setup and configured to be a generic VM from which our linked clones will branch.

The Branches

This is the linked clone replica. This is a duplicate copy of the snapshot taken of the base image.  The replica is used as the “base” for all linked clones attached to it, for the terms of space saving and efficiency. Each linked clone pool will have at least one replica, one per snapshot in use.

The Leaves

Each linked clone VM within a pool is a leaf. Each leaf is attached to a branch which is attached to a trunk. The linked clone VM is not a standalone VM, but is a combination of the replica and a difference disk. The difference disk contains every disk write made after the replica is created.

The Roots

This is your vCenter. View Connection Server provides access, View Composer creates requests for cloning and customization, but your vCenter runs the whole show and makes things happen. Everything hooks into your vCenter.

How does it all work?

First, you need to create the template and prepare it for use. This includes installing VMware tools and the View Agent. Once you have all Operating System and application installed and updates complete, the template is ready, to be shut down and it’s snapshot is taken.
Within the View administrator, you will configure the pool to point at the specific base image and select the appropriate snapshot. Multiple pools can point to different images, the same image and snapshot, or the same image and different snapshots.
Once the pool is created, Composer will then request that vCenter clone a replica machine for use by the pool, and create the number of VMs needed to satisfy its pool requirements. This is where the linked clone machine is different than a standard VM. The replica contains everything that is needed to run Windows. It has all of the OS files, boot files and applications. The linked clone VM attaches to this so every linked clone shares the same Windows installation. A disk is created that contains the changes made for an individual VM. This checkpoint contains the domain and naming information and other basic information (the customization information) required to differentiate it from other linked clones attached to the same replica.
The linked clone can be customized in one of 2 ways. Sysprep (a Microsoft tool) uses a vCenter customization template that can be utilized to provide information on customizations to be performed. The second option is to use Quickprep which is Composer’s built in customization tool, and is generally recommended unless a Sysprep-specific customization is required.
At this point, the difference disk is created and all disk writes from that point on are saved to the difference disk. The replica is not modified, and the checkpoint contains all of the customization information that would be needed in the event the linked clone needs to be refreshed.

we covered the basics of what a linked clone is, the basic structure, and how a linked clone is provisioned. In this follow-up piece, we'll look at the 3 major operations performed on a linked clone. Refresh, recompose, and re-balance.

Refresh

As mentioned  a checkpoint is created containing the individual customizations to the VM that differentiates it from the replica. This checkpoint contains things like the machine password, domain information, Windows name, etc. This checkpoint is a snapshot of the VM post customization. The refresh operation reverts the VM to this checkpoint snapshot.
View Connection Server changes the status of the VM to Maintenance to tag it as unusable, reverts to the previous checkpoint snapshot, and after start-up, the View Composer agent updates the machine account password if needed. View Connection Server then sets the machine back to Provisioned, or Available to meet the pool requirements.
The Desktop is now ready for use.

Recompose

A recompose lets you redeploy an existing View desktop while preserving any persistent or user data disks that may be attached to the VM.
When a recompose is performed with no configuration change (no new snapshot), no recompose will occur because Composer will detect that no changes will be made. The difference between using an existing template/snapshot and a new template/snapshot is a new replica is needed with a new snapshot. The new replica is cloned from the snapshot, and a new checkpoint and difference disk are created.
View changes the status of the desktop to Maintenance and creates the new snapshot if needed. Though the VM hardware is not replaced, this is a new VM and is customized using the same process as a newly provisioned desktop with a new checkpoint and difference disk. View then sets the machine back to Provisioned, or Available to meet the pool requirements.
The difference between using an existing template/snapshot and a new template/snapshot is a new replica is needed with a new snapshot. The new replica is cloned from the snapshot, and a new checkpoint and difference disk are created.
View Connection Server changes the status of the desktop to Maintenance and creates the new snapshot if needed. Though the VM hardware is not replaced, this is a new VM and is customized using the same process as a newly provisioned desktop with a new checkpoint and difference disk. View then sets the machine back to Provisioned, or Available to meet the pool requirements.

Re-balance

A re-balance serves 2 purposes-
  1. It will redistribute linked clones to use available free storage space.
  2. It is the only supported method to migrate linked clones between datastores. Storage vMotion will break a linked clone.
A re-balance will try to ensure all configured datastores are equally used based on the amount of available free space. I will not be discussing the algorithm used here because it is dependent on the version of View and the storage over commit settings. View will investigate each datastore the pool is configured to use, and determine which linked clones to migrate. It is possible during a re-balance that no desktops will be migrated. A refresh operation will also occur on all affected desktops.
When a re-balance occurs, the VM status is changed to Maintenance. View will then detach any persistent disks and move them and the VM to the new datastore. The persistent disks are attached to the VM at the new location. If a replica for the pool does not exist at the new location, Composer will request a new replica to be cloned by vCenter to be placed on that datastore. Composer will then attach the linked clone to the replica and customization occurs with a new checkpoint and difference disk. View will then set the machine back to Provisioned, or Available to meet the pool requirements.
A re-balance can also be used to vacate a datastore. Deselecting a datastore from a linked clone pool settings and then performing a re-balance on the pool will cause all associated linked clones from the pool to be migrating to another datastore (when possible). This is often used to migrate a linked clone pool from one datastore to another.
This covers the basics of what a linked clone is, and what maintenance and administrative options are available.

Horizon View has a few different types of desktop pools.  Each pool handles desktops in different ways, and they each have different purposes.  The type of pool that you select will be determined by a number of factors including the use case, the storage infrastructure and application requirements.

The type of desktop pools are
  • Full Clone Pools – Each virtual desktop is a full virtual machine cloned from a template in vCenter.  The virtual machines are managed by View Connection Servers.
  • Linked Clone Pools – Each virtual desktop is based on a snapshot and shares its disk with the parent virtual machine.  Changes to the linked clone are written to a delta disk.  The virtual machines are managed by View Composer.
  • Manual Pools – The machines that make up the manual pool consist of virtual and/or physical machines that have had the View Agent installed.  These machines are not managed by View.
  • Terminal Services Pool – The machines that make up these pools are Windows Servers with the Remote Desktop Services Role installed.
There is one other choice that needs to be selected when creating a desktop pool, and that is the desktop assignment type.  There are two desktop assignment types:
  • Floating Assignment – Desktops are assigned to users at login and are returned to the pool of available desktops when the user signs out.
  • Dedicated Assignment – Desktops are assigned to a user, and the user gets the same desktop at each login.  Desktops can be assigned automatically at first login or manually by an administrator.

vCenter Orchestrator Appliance

As I start to update my lab with a fresh new build, I wanted to make sure I have all the tools i’ll need to take the Automation journey and to sharpen my skill-sets around the tools that VMware offers, PowerCLI, vCenter Orchestrator, and vCloud Automation Center.
In the past I have seen vCenter Orchestrator installation and configuration a bit painful and I have read in other blogs and social networks that I wasn’t the only one having issues with the initial configuration.
I’m happy to report that the latest Appliance version of vCO is a breeze to install and configure just like many of VMware’s appliance-based solutions like the vCenter Server Appliance and the vCenter Support Assistant, to name a few.  VMware is making it much easier to deploy these solutions with the appliance model, at the same time, lessening some of the license burden that our customer’s bear regarding Operating Systems and Database licensing.
The first Appliance I will cover is the latest vCO Appliance 5.5.2 which can be downloaded here.  The .OVA file is around 800MB in size.
Of course, prior to deploying the .OVA, we want to make sure that we have all the information we will need prior to the installation such as DNS Name and Entry, IP information, and passwords for both root and vmware built-in accounts.
When you have all the prerequisites
Deploy the Appliance(ova) from web client or window client
 Review the details and Click Next
 Accept the EULA and Click Next
 Select the Name and Folder and Click Next
 Select the Storage and Click Next
 Setup your Network that vCO
 Give password to root and VCO interface password
also provide hostname: FQDN and DNS Information:
 Check Power on after Deployment and Click Finish
 When vCO powers on wait for some time to loadup vapp, once it is completely powered On.  You can access this by going to this link:
https://<your vco ip or fqdn>:5480
Log in as root and the password 
 If you’ve already worked with any VMware Appliances this interface should be very familiar.  Here we validate all my settings,  change my Timezone
  check for updates, if you have downloaded latest version no need to perform update check.
 Now we are ready to move on to the vCenter Orchestrator Configuration which you can access by going to this link:
https://<your vco ip or fqdn>:8283
This time, log in as vmware with the password you chose during deployment.

 Let’s move to Authentication in the left hand column.  Choose SSO as your Authentication mode and supply the SSO server information and credentials and select Register Orchestrator.  In my case, it found my AD as a valid SSO Authentication Source and I listed Domain:Domain Admins and selected Update Orchestrator Configuration.
 *Very important: The next step is to restart the vCO Server Service.  I found that this is required to accept the changes
Choose Startup Options in the left hand column and click the Restart service link under vCO Server.
 After the service has been restarted now we are ready to add our vCenter Server.  Choose vCenter Server (5.5.2) in the left hand column and the New vCenter Server Host tab,  fill in all the appropriate information to add the vCenter Server and choose Apply Changes:
 And that’s it for the basic install.  Now let’s go check the vCenter Web Client to make sure that vCO is linked to vCenter and let’s test a Workflow to validate functionality.
Launch your Web Client and Select vCenter Orchestrator under Inventories:
 Here we can now see one vCO Server listed
 Let’s test a workflow.  Click on Scheduled workflows then Schedule a Workflow. Expand the vCO server and you will see a list of Library folders that contain built in, out of the box workflows for Orchestrator.  Scroll down to vCenter and expand the folder to Host management, then Basic.  Here you will see a list of prebuilt Workflows.  We will test vCO functionality by simply putting a host in maintenance mode so choose Enter maintenance mode and then hit Next:
 Click on the + symbol next to the empty field under Host to put in maintenance mode then select Filter and choose the host:
 Click OK then click Next. Choose Run now then hit finish.
 Now we can see VM’s are being migrated after a Maintenance Mode operation has been kicked off:
 And here is the outcome from the Workflow:

There ya have it.  We installed and configured the vCenter Orchestrator Appliance and ran a simple built-in Workflow to validate functionality.