Attempting to “Get Device Image” from within Dell Wyse Device Manager Version 5.0 errors with: “can’t access tty; job control turned off”

Problem

You attempt to use the Get Device Image feature (non PXE) from within Dell Wyse Device Manager Version 5.0 to pull an image off of a Wyse Thin Client:

The WDM Server is able to restart the Thin Client and begin the process of uploading the server but you notice that the progress never increases from 0% and eventually errors out with:

BusyBox v1.00 (2007.02.08-11:26+0000) Built-in shell (ash)

Enter ‘help’ for a list of built-in commands.

/bin/sh: can’t access tty; job control turned off

/bin #

Nothing happens and you are forced to restart the thin client.

Solution

The Wyse thin client I was working with was an older Z90S7 model and apparently had an older Boot Agent that needed to be updated so from within the Wyse Device Manager console, I navigated to Package Manager –> Other Packages then dragged and dropped the BootAgent item to the Device Manager node:

Continued through the wizard and selected the thin client to be updated:

I was then able to successfully pull the image from the Wyse thin client once the boot agent was updated:

VMware Horizon View 5.3.2 build 1887719 connection servers display the error message: “One or more View Composer backups failed. See the event log for more details.”

Problem

You have 2 VMware Horizon View Connection servers with the version 5.3.2-1887719 in your environment that displays a red exclamation mark under the Last Backup column:

Hovering over the red exclamation mark displays the message:

One or more View Composer backups failed. See the event log for more details.

Solution

This apparently is a bug in version 5.3.2 build 1887719. The message will no longer appear once the connection servers are upgraded to version 6: 

How to send CTRL+ALT+DELETE from Windows 7 Embedded Thin Client to VMware View VDI desktop

Problem

One of the most common questions I get asked from clients setting up thin clients is how to pass key combinations such as CTRL+ALT+DELETE that Windows is designed to intercept for security reasons to a VMware View desktop. For those who have worked with Windows 7 Embedded Thin Clients would know that the default behavior when a user presses CTRL+ALT+DELETE in their VMware View desktop is that the user would get presented with the Thin Client’s CTRL+ALT+DELETE options rather than their VMware View desktop.  This is also the same for other key combinations such as ALT+TAB and CTRL+SHIFT+ESC.

Before I write the solution, note that the following would not work:

How to enable or disable the CTRL+ALT+DELETE sequence for logging on to Windows XP, to Windows Vista, and to Windows 7
http://support2.microsoft.com/kb/308226

The above solution doesn’t work because it disables the need to use the CTRL+ALT+DELETE sequence during user logon.

The following policy that exists in the Windows Embedded operating system also would not work:

Computer Configuration –> Administrative Templates –> System –> Keyboard Filter –> Security Keys –> Block Secure Desktop (Ctrl+Alt+Del)

Enabling the policy above only renders the key sequence to not do anything.

It also doesn’t help that trying to Google the words Ctrl+Alt+Del, virtual desktop, thin client, etc. usually yields the 2 results from above.

Solution

The solution to the problem is actually quite simple and that is to load the PCoIP ADM template and enable:

Use Enhanced Keyboard on Windows Client if available

More information about this configuration can be found here:

View PCoIP Session Variables for the Keyboard
http://pubs.vmware.com/view-50/index.jsp?topic=/com.vmware.view.administration.doc/GUID-2FA7564D-FF3E-472B-AD2D-575CCCD82410.html

The requirements for using this feature are as follows:

1. You need to use the VMware View Client with Local Mode
2. You need to run the View Client with Local Mode as an administrator

The following summarizes the problems I immediately had with the requirements above:

1. The View Local Mode capability has been removed from the Windows client in the Horizon View 6.0 release which leads me to believe it will no longer be updated thus requiring a replacment
2. You cannot simply run the the View Client with Local Mode with a service account that is a local administrator on the thin client because doing so would prevent you from using the “Log on as user feature” and even if that feature worked, it would be a security risk putting a password into a batch file

I was unable to find any workarounds to the above concerns but what I did find was the following setup provided by a user on the VMware forums:

https://communities.vmware.com/message/2332945

What the user did was essentially run the VMware View Client with Local mode via a script that would automatically log the user off if the client is closed. When combining this script with disabling the VMware View client bar, a user is essentially locked into their View VDI until they log off and in which case would log them off the client.

While this isn’t a perfect solution, most administrators may have to live with it until new features are released.  I will update this post if I come across something better.

Attempting to pull and image from a Wyse thin client fails with: “Copy image to USB failed Press Enter key to reboot now.”

Problem 

You have the current thin client model:

Brand: Wyse
Model No: Zx0
Part No: 909682-01L

You would like to pull the image after staging the thin client so you proceed to download the Wyse USB Firmware Tool from the following site:

http://www.dell.com/support/home/bz/en/bzdhs1/product-support/product/wyse-z90d7/drivers

https://appservices.wyse.com/pages/serviceandsupport/support/downloads.asp

https://appservices.wyse.com/pages/serviceandsupport/support/dlOraFW.asp?which=102&model=USB%20Firmware%20Tool(Wyse Imaging Tool)

You run the Wyse USB Firmware Tool.exe to prepare the USB flash drive:

… but quickly notice that you receive the following error at the Prepare the USB drive window:

USB drive size less than 1GB, please insert higher capacity drive

You close the application and re-launch it by choosing Run as administrator:

The wizard successfully passes the step you received the error:

 

With the successfully prepared USB stick, you proceed to pull the image but notice that the process completes at 100% but quickly displays the following error:

Copy image to USB failed

Press Enter key to reboot now.

 Solution

This issue managed to get me stumped for an hour as I continued to try 4 different version of the tool without any luck until I decided to try selecting:

Windows Embedded Standard 7

… instead of:

Windows Embedded Standard 7 P

Once I selected the correct operating system, the pull operation completed successfully.  I was unable to find any material online so I hope this blog post will serve a quick answer to anyone who made the same mistake as I did.

Citrix XenApp 7.5 Site Setup fails when creating a new database

Ran into an interesting issue the other day that was easy to fix but noticed that the error message could be misleading so I thought it would be a good idea to write a blog post in case other encounter this.

Problem

You’re setting up a new Site in XenApp / XenDesktop Studio and would like the wizard to create a new database so you proceed with filling in the database server location and database name as such:

You then hit the Test connection button:

You receive the prompt:

No database was found on the database server.

To create a database automatically, click OK.

Or, if you would prefer to use the database schema to create a database, click Cancel.

You proceed to hit OK to allow the wizard to create a new database:

… but notice that you are prompted with the following message:

The current credentials have insufficient privileges to access the database server and perform the necessary operations. Do you wish to enter alternative credentials?

You are sure that you’ve logged onto the server to run this wizard with an account that has permissions but go ahead and type in the credentials again:

After typing the credentials and hitting the OK button, you are prompted with the same message:

The current credentials have insufficient privileges to access the database server and perform the necessary operations. Do you wish to enter alternative credentials?

Solution

What I noticed after a bit of troubleshooting was that the firewall on the SQL server was turned on and as soon as I disabled the firewall, the wizard proceeded:

It’s definitely a bit strange that the message would indicate an issue with the account when it’s related to the firewall but I hope this post would serve up a quick answer to those who encounter this.

Emails to distribution groups do not get delivered while migrating from Exchange 2007 to 2013

I ran into a rather tough issue that got me stumped for a few hours and thought it’s worth blogging.  The problem is that all of a the distribution groups in an environment I’m migrating from Exchange 2007 to 2013 does not get delivered and eventually generates the following bounce back NDR:

Diagnostic information for administrators:
Generating server: exchange2013.contoso.local
Receiving server: exchange2007.contoso.local (192.168.9.2)
secondary@contoso.com
Remote Server at exchange2007.contoso.local (192.168.9.2) returned '400 4.4.7 Message delayed'
9/10/2014 2:54:59 PM - Remote Server at exchange2007.contoso.local (192.168.9.2) returned '441 4.4.1 Error encountered while communicating with primary target IP address: "Failed to connect. Winsock error code: 10061, Win32 error code: 10061." Attempted failover to alternate host, but that did not succeed. Either there are no alternate hosts, or delivery failed to all alternate hosts. The last endpoint attempted was 192.168.9.2:25'
Original message headers:
Received: from exchange2013-2.contoso.local (10.10.7.33) by exchange2013.contoso.local
(10.10.7.32) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 10 Sep
2014 08:00:54 -0300
Received: from exchange2013-2.contoso.local ([fe80::e183:a641:f02:ceb1]) by
exchange2013-2.contoso.local ([fe80::e183:a641:f02:ceb1%16]) with mapi id
15.00.0847.030; Wed, 10 Sep 2014 08:00:54 -0300
Content-Type: application/ms-tnef; name="winmail.dat"
Content-Transfer-Encoding: binary
From: Kate Ross <kross@contoso.com>
To: secondary <secondary@contoso.com>
Subject: Wed. Cover/Calendar
Thread-Topic: Wed. Cover/Calendar
Thread-Index: Ac/M5l84/Y7M2h8hSKKr2Unpc4VGhA==
Importance: high
X-Priority: 1
Date: Wed, 10 Sep 2014 08:00:53 -0300
Message-ID: <b1b6f4f8ddd847579cafe082b03e3e85@exchange2013-2.contoso.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: <b1b6f4f8ddd847579cafe082b03e3e85@exchange2013-2.contoso.local>
MIME-Version: 1.0
X-Originating-IP: [10.51.1.102]
Return-Path: kross@contoso.com

The troubleshooting steps I’ve performed are:

Upgrading from Exchange 2007 to 2013

Upgrade the distribution groups from Exchange 2007 to 2013 by first listing the groups’ versions with the cmdlet:

Get-DistributionGroup | fl *version

Then executing:

Get-DistributionGroup | Set-DistributionGroup

Once the above cmdlet is executed, the…

Get-DistributionGroup | fl *version

… cmdlet should now display the version as:

ExchangeVersion : 0.10 (14.0.100.0)

Upgrading Distribution Groups to Universal

Upgrading the distribution groups did not appear to correct the issue so after a bit more troubleshooting, I discovered that all of the groups were still of Global type rather than Universal so I went ahead and upgraded them with:

Get-DistributionGroup | where { $_.Grouptype -Like "Global*" } | Set-Group -Universal

Note that if any of the distribution groups have members or are members of Global groups then the associated groups will also need to be upgraded to Universal.

Removing the homeMTA Attribute

After trying the troubleshooting steps above and still encountering the same messages stuck in the queue with the message:

Next Hop Domain: Exchange2007server.domain.local

Delivery Type: SMTP Relay to specified Exchange servers

Status: Retry

With the message details:

Identity: Exchange2013\12736\2598455214130

Subject: Testing123 - No need to reply

Internet Message ID: <ae09691dea2a4c2eb147da76d594518e@BHS-EXMBX-01.domain.local>

From Address: CCS-User@domain.bm

Status: Ready

Size (KB): 7

Message Source Name: SMTP:Default Exchange2013

Source IP: 10.10.7.32

SCL: -1

Date Received: 9/12/2014 10:14:43 PM

Expiration Time: 9/14/2014 10:14:43 PM

Last Error:

Queue ID: Exchange2013\12736

Recipients: staff@domain.bm;2;1;[{LRT=};{LED=};{FQDN=};{IP=}];0;CN=Exchange2007,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Domain,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=local;0

 

I then started combing through the difference between a newly created distribution group I created with the Exchange 2013 ECP and an existing distribution group that wasn’t working. Using the cmdlet:

Get-DistributionGroup "<distribution group name>" | fl

… did not not show any differences side by side so I went ahead and opened adsiedit comparing the attributes which was when I noticed that the new distribution group created with Exchange 2013 did not have a

… while an old distribution group did:

As soon as I cleared the attribute from the problematic distribution group, the messages were delivered.

Import-Module ServerManager

Add-WindowsFeature -Name "RSAT-AD-PowerShell" -IncludeAllSubFeature

Unfortunately, you would need to restart the server before you can import the Active Directory cmdlets with the following import command (I noticed that sometimes I wouldn’t need to run it yet the AD cmdlets would work):

Import-Module ActiveDirectory

Once you have access to the AD cmdlets, you can use the following cmdlet to clear the homeMTA attribute:

Set-ADGroup ‘<distributionGroupName>’ -Clear homeMTA

I originally thought that I could pipe the results from Get-DistributionGroup into Set-ADGroup but that doesn’t work so the way I worked around this was use:

Get-DistributionGroup | FL name > C:\DistroNames.txt

… to get the names of all of the distribution groups in the format:

Name: Distro1

Name: Distro2

… into a text file then opened it in notepad and used a search and replace to format it properly with the Set-ADGroup cmdlet to execute.  Not exactly the most elegant solution but it works.

Unable to connect Android mobile phone to Exchange Server 2013 via ActiveSync

Problem

You’ve completed a new Exchange Server 2013 migration and began testing mobile devices such as Android and iPhone but noticed that while you are able to go through the setup, no mail is synchronized to the smart phone.  Not events are logged in the Application or System logs of the Exchange mailbox and CAS servers. Using the Microsoft Remote Connectivity Analyzer at https://testconnectivity.microsoft.com fails with the following error:

Attempting the FolderSync command on the Exchange ActiveSync session.
  The test of the FolderSync command failed.
   Tell me more about this issue and how to resolve it

  Additional Details

Exchange ActiveSync returned an HTTP 500 response (Internal Server Error).

HTTP Response Headers:
request-id: c257a25d-2589-4c25-8190-491bacfaadb3
X-TargetBEServer: ********.*******.*****

Solution

While there could be other reasons why this error would be thrown, one of the reasons is because the user account you’re trying to set up ActiveSync with does not have inheritance enabled as shown in the following screenshot:

Simply enabling inheritance and the phone should begin synchronizing email.