Citrix XenDesktop 7.15 reboot issues

Citrix XenDesktop 7.15 reboot issues

During our migration from XenApp 6.5 to 7.15 we encountered some issues with reboots.

Several reboot schedules were created using the New-BrokerRebootScheduleV2 cmdlet as follow: 

PS> New-BrokerRebootScheduleV2 @props -Name Reboot_XYZ_0630_30 -DesktopGroupName DG_XYZ -RestrictToTag Tag_Reboot_XYZ -StartTime 06:30 -RebootDuration 30

Yet, out of 14 Delivery Groups only one would actually create reboot cycles.
Also, the VMToolsState was inconsistently being reported in XenDesktop.
It woud change from NotStarted to Running after a machine reboot and then would switch back to NotStarted when changing the reboot cycle day....

PS> Get-BrokerMachine | select hostedmachinename, vmtoolsstate, powerstate, registrationstate

HostedMachineName VMToolsState PowerState RegistrationState

----------------- ------------ ---------- -----------------

xxxxxxxxx               NotStarted         On        Registered

xxxxxxxxx               Running            On        Registered

xxxxxxxxx               Running            On        Registered

xxxxxxxxx               NotStarted         On        Registered

xxxxxxxxx               NotStarted         On        Registered

Given that the issue affected all Delivery Groups but one, a quick comparison of the properties of the working vs non-working ones with the Get-BrokerDesktopGroup cmdle highlighted that the non-working Delivery Groups did not have any TimeZone property setup. 

As per https://citrix.github.io/delivery-controller-sdk/Broker/Set-BrokerDesktopGroup/
"The time zone must be specified for any of the group's automatic power management settings to take effect. "

The discrepancy was caused by the scripted creation of Delivery Groups as part of the application import script. The Delivery Group for which the reboots worked well was the one that had been created manually... sight...

So if you decide to script Delivery group creation bare in mind that you will also need to set the TimeZone property appropriately. 

Set-BrokerDesktopGroup -Name DG_XYZ -TimeZone "W. Europe Standard Time"

To find your time zone, you can use the command below:

tzutil.exe /l 

I hope this will help a few.... 

References:

https://www.citrix.com/blogs/2017/03/02/reboot-schedule-internals/

https://www.citrix.com/blogs/2017/01/10/multiple-reboot-schedules-for-a-delivery-group-in-xenapp-7-12/

https://developer-docs.citrix.com/projects/delivery-controller-sdk/en/latest/Broker/New-BrokerRebootScheduleV2/

https://stealthpuppy.com/xendesktop-delivery-group-powershell/

Could not initialize installation C:\~GLC1034.tmp the system cannot find the file specified

Work Around - "Could not initialize installation C:\~GLC1034.tmp the system cannot find the file specified"

Long time since my last post but I since I could not find much useful info on the internet regarding this issue, I thought I would take a few minutes to share a work around. 

When trying to install an EXE packaged with Wise you get the below error: 

As a work around download PsExec and open cmd as system user to install that package.

1. Open CMD as admin

2. Run "PsExec -s -i cmd.exe"

3. A new cmd window appears, that windows in running in the SYSTEM context and you can perform your installations from there.

That's it for now, if you have any info on the root cause, please comment!! 

SCCM: "An error occurred while retrieving policy for this computer (0x80072EE7)" in WinPE

The Error:

Error 0x80004005 right at the beginning of the process.

The smsts.log shows 

Other Symptoms:

Client gets a DNS IP like fec0:0:0:fff::1%1

Solution:

Check and if required set the DHCP option 6 to define the DNS server address.

http://technet.microsoft.com/en-us/library/cc958941.aspx

HOW-TO Populate MDT Database Roles using a Powershell Script

I recently had to build additional MDT servers to deploy our OSes and one of the task I dreaded was adding the roles properties to the MDT database manually. 

Not only it takes time but it is also very error prone, i.e.: update the wrong field, misspel the admin password,....

After searching the internet I was able to put this script together and use it to add our roles on each server.

I hope you enjoy it and it helps you save some time.

Until next time ...

#Download MDTDB module from URL:
#http://blogs.technet.com/b/mniehaus/archive/2009/05/15/manipulating-the-microsoft-deployment-toolkit-database-using-powershell.aspx

########################### Variables initialization ###########################

#To import the MDT Database and MicrosoftDeploymentToolkit Powershell module
$MDTDB_Module_Path = "E:\MDTDB\MDTDB.psm1"
$MDT_Module_Path = "C:\Program Files\Microsoft Deployment Toolkit\Bin\MicrosoftDeploymentToolkit.psd1"

#Server name or IP to connect to the database
$Servername = "10.10.10.10"

#To set the name of the database where we want to add roles
$DatabaseName="MDTUATDatabase"

#Array to add applications to each role - Apps GUIDs are server specific.
$Apps=@('{435c616b-80a7-43ef-8a91-d1ea95ca2a89}','{999c616b-ab77-43ef-8a91-d1bd5ca2a10}')

####################################  Main ####################################

#Import the MDT Database Powershell module

import-Module $MDTDB_Module_Path

#Import MicrosoftDeploymentToolkit module
import-module $MDT_Module_Path

#Create a PSDrive to the MDT Deployment Share
New-PSDrive -Name (Get-MDTPersistentDrive).Name -PsProvider MDTProvider -Root (Get-MDTPersistentDrive).Path -Verbose

#Create a new Database ( optional)
#New-MDTDatabase -Path "DS001:" -SQLServer $Servername -instance "SQLEXPRESS" -database $DatabaseName -SQLShare "\\$Servername\DeploymentShare$"

#Connect to the database
Connect-MDTDatabase -sqlServer $Servername -instance "SQLEXPRESS" -database $DatabaseName

#Set role specific variables
#Role name that appears in the MDT Gui
$RoleName = 'Europe-Germany-UAT'

#Hash table with details tab entries for the above role
$Settings=@{
'OSInstall' = 'YES'
'JoinDomain' = 'MY.LAB.CORP'
'DomainAdmin' = 'MyDomainAdminAccount'
'DomainAdminDomain' = 'LAB'
'DomainAdminPassword' = 'xyz123456789'
'MachineObjectOU' = 'OU=Workstations,OU=Computer Accounts,DC=MY,DC=LAB,DC=CORP'
'TimeZoneName' = 'W. Europe Standard Time'
'KeyboardLocale' = '0407:00000407'
'InputLocale' = '0407:00000407'
'UserLocale' = 'de-DE'
'SystemLocale' = 'de-DE'
'UILanguage' = 'de-DE'
'SkipCapture' = 'yes'
'SkipAdminPassword' = 'yes'
'SkipApplications' = 'yes'
'SkipComputerBackup' = 'yes'
'SkipDomainMembership' = 'yes'
'SkipUserData' = 'yes'
'SkipLocaleSelection' = 'yes'
'SkipProductKey' = 'yes'
'SkipSummary' = 'yes'
'SkipBDDWelcome' = 'yes'
'SkipTimeZone' = 'yes'
'SkipBitLocker' = 'yes'
'SkipDiskPart' = 'yes'}

#Add the role with above params
New-MDTRole -name $RoleName -settings $Settings | Set-MDTRoleApplication -applications $Apps

#Repeat the process for each new role

$RoleName = 'Europe-Italy-UAT'
$Settings=@{
'OSInstall' = 'YES'
'JoinDomain' = 'MY.LAB.CORP'
'DomainAdmin' = 'MyDomainAdminAccount'
'DomainAdminDomain' = 'LAB'
'DomainAdminPassword' = 'xyz123456789'
'MachineObjectOU' = 'OU=Workstations,OU=Computer Accounts,DC=MY,DC=LAB,DC=CORP'
'TimeZoneName' = 'W. Europe Standard Time'
'KeyboardLocale' = '0410:00000410'
'InputLocale' = '0410:00000410'
'UserLocale' = 'it-IT'
'SystemLocale' = 'it-IT'
'UILanguage' = 'it-IT'
'SkipCapture' = 'yes'
'SkipAdminPassword' = 'yes'
'SkipApplications' = 'yes'
'SkipComputerBackup' = 'yes'
'SkipDomainMembership' = 'yes'
'SkipUserData' = 'yes'
'SkipLocaleSelection' = 'yes'
'SkipProductKey' = 'yes'
'SkipSummary' = 'yes'
'SkipBDDWelcome' = 'yes'
'SkipTimeZone' = 'yes'
'SkipBitLocker' = 'yes'
'SkipDiskPart' = 'yes'}

#Add the role with above params
New-MDTRole -name $RoleName -settings $Settings | Set-MDTRoleApplication -applications $Apps

FIX: "LTIApply: Path not found (76)" - building Hyper-V VM

I recently got an issue that I had fixed before but could not remember how ... better post it once and for all. 

When deploying an image on an Hyper-V VM with MDT 2012 Update 1 or MDT 2013, at the beginning of the process - in the WinPE stage - I got the "ZTI ERROR - Unhandled error returned by LTIApply: Path not found (76)"

After checking various logs - which are still located on the ramdisk at that stage of the sequence - I found in the Variable.dat  that the properties IsDesktop and IsVM where both set to True. This was also showing in the ZTIGather log.

Checking the ZTIGather.wsf it appears that this occurs because the script is using different methods to set the properties IsVM and IsDesktop.  The chassis type of the Hyper-V VMs is matching those of a Desktop, whilst Model and BIOS description version are also setting the property isVM to true.

 One work-around - involving modifying the customsettings.ini - is described in this technet forum post.

Another work-around, is to modify your task sequence to add a step that sets IsDesktop to False right before the "Format and Partition ... " steps.

Here is the step from the ts.xml:

"
      <step type="SMS_TaskSequence_SetVariableAction" name="HyperV variable set" description="" disable="false" continueOnError="false" successCodeList="0 3010">
        <defaultVarList>
          <variable name="VariableName" property="VariableName">ISDesktop</variable>
          <variable name="VariableValue" property="VariableValue">False</variable>
        </defaultVarList>
        <action>cscript.exe "%SCRIPTROOT%\ZTISetVariable.wsf"</action>
        <condition>
          <expression type="SMS_TaskSequence_WMIConditionExpression">
            <variable name="Namespace">root\cimv2</variable>
            <variable name="Query">SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "%Virtual%"</variable>
          </expression>
        </condition>
      </step>
"

I hope this post will save you some time. Enjoy !! 

Powershell: One liner to output logon events including LogonType and UserName

Here is a small powershell command that will extract the latest events of type "logon" or event ID 4624 with their logontype and the TargetUserName. 

get-eventlog -LogName Security -instanceID 4624 -newest 100 | %{ $arrMSG = $_.Message -Split "`n"; $LogonType = $arrMSG[8]; $TargetUserName = $arrMSG[12]; Add-Member -MemberType NoteProperty -Name LogonType -Value $LogonType -InputObject $_; Add-Member -MemberType NoteProperty -Name TargetUserName -Value $TargetUserName -InputObject $_; $_ | select TimeGenerated, InstanceID, LogonType, TargetUserName} | ft -AutoSize -wrap

Info on the logon types and their meaning can be found on the web , i.e.: here.

The same can also be achieved using WMI and  XML but in this case I opted to split the Message property into an array and access the data by row number. Here is a discussion on Technet regarding using WMI instead.

HOW TO: Migrate large VMDK content to VHD when everything else fails

The Task: 
Migrate our lab server (IBM x3655) - so that it supports Windows 8. 8.1 and equivalent server versions - from  ESXi 3.5 Update 5 (Highest version officially compatible with the hardware) to Hyper-V 2012R2.

The Setup: 
Staged a desktop with windows 8.1 and Hyper-V to use as a "pivot" to store my converted VMs and ensure they do work properly before reinstalling the Server OS.

The Problem(s): 
After I had successfully converted over the network my smaller VMs ( Disk of 40GB or less) using 5nineEasyConverter I could not convert the larger VMs this way and would get conversion errors of some sort.
I spent a lot of time testing different products including WinImage and VMDK2VHD but did not have much success.

The work-around : 
Out of options, I decided to boot my VMs on a WinPE image and use IMAGEX to capture their content to a WIM file to then apply this to a new VHD(X).

Note that regardless of the method you use when converting your VMs from one vendor to another always uninstall the "integration" software from the VM before hand. If you use all in one converters like the one mentioned above also ensure your VMs don't have any snapshots, since in this instance we are capturing the disk content, we don't really care about snapshot and this method could be used if you are unable to merge your snapshot with your VM for whatever reason.

Since capturing VMs running in iSCSI mode and migrating those to IDE mode in HyperV, extra steps were required (point #7 and following) to fix the boot error "0xc000000e The boot selection failed because a required device is inaccessible.".

1. Map a share from  in the WinPE environment to the box where you want to store your migrated VMs.
2. Put a copy of Imagex.exe on the WinPE RAM Disk under X:\Windows\System32 for ease of use.
3. Run: Imagex /CAPTURE C:\ Z:\MylargeVM1.WIM "My Large VM OS Disk"
4. Let the capture finish ( it does take a while but less than any of the other products tried before).
5. Create a new VHDX on your "pivot" box with Diskpart, attach it, create a primary partition, format it, make the partition active (else it wont boot either) and assign a letter to it (i.e.: F:).
6. Apply the WIM to the new VHDX by running:  Imagex /Apply D:\MylargeVM1.WIM 1 F:\
   Note: At that point I did detach the VHD, created a new VM in Hyper-V using this existing disk but the VM failed to boot and was throwing an error "0xc000000e The boot selection failed because a required device is inaccessible." The following steps are to apply the fix KB314082 to solve this problem.
7. Mount the SYSTEM hive of your new VHD(X) in the "pivot" box registry editor:
   From Regedit, select HKLM and go to File > Load Hive. Navigate to F:\Windows\System32\config and select SYSTEM. Mount the hive as Z.
8. Copy the entries under "Windows Registry Editor Version 5.00" from KB314082 to a .reg file and replaced "HKEY_LOCAL_MACHINE\SYSTEM" with "HKEY_LOCAL_MACHINE\Z\SYSTEM".
9.  Run the newly created .REG to add the entries to the loaded SYSTEM hive.
10. Unload the Hive, Detach you VHD, Create your VM in HyperV and boot it up. Hopefully you should be all good.

I hope this will be useful to a few and if you have other solutions please do use the comment section to share them! Enjoy !!