Citrix XenApp Publishing Windows Explorer

We are in the process of upgrading our Citrix farm from XenApp 5 on Windows 2003 to XenApp 6.5.  One of our requirements was to publish a seemless windows version of Explorer.  In Windows 2003 this was easy, but since Microsoft decoupled explorer from IE and now whenever explorer.exe is called, the launched instance now exits and opens a new instance two problems occur.

1. The XenApp AppCenter does not think the launched application is working anymore so you do not see information under connected users

2. As soon as the session starts, it closes down again unless another process is holding it open!

There are many solutions to this availble, but none quite did the trick for me as all the ones I tried had limitations.

With a combination of a batch file, sleep.exe and hstart.exe I was able to not only get the session to stay alive while explorer was running, but also show the correct info in the AppCenter and logoff correctly when explorer was closed.

The published application should look like this:

%path%\hstart64.exe /NOCONSOLE %path%\ExplorerStart.bat

The batch file looks like this:

@echo off
ECHO Starting explorer
C:\Windows\explorer.exe
:LOOP
ECHO Checking for explorer.exe
TASKLIST /FI "USERNAME eq %userdomain%\%username%" /FI "Imagename eq explorer.exe" > %temp%\explorercheck.txt
ECHO Sleeping for 30 seconds
%path%\sleep.exe 30
set folder=%temp%\explorercheck.txt
for /f "eol=: tokens=3 delims= " %%a in ('find "explorer.exe" %folder%') do (
   GOTO LOOP
)
ECHO Explorer not found so deleting text file and exiting
del  %temp%\explorercheck.txt
exit


I imagine there are more elegant ways of writing the batch file, but this works nicely for me.

%path% needs to be substituted for a real path in three locations.

Hope this saves someone a bit of time.

AppV Unload All Apps

I have been having an issue where AppV is writing absolutely loads of temporary files in C:\ProgramData\Microsoft\Application Virtualization Client\SoftGrid Client\AppFS Storage. In fact I had >6000 temporary files for each every application on my RDSH servers - two files are created for each and every user who loads the application, each and every time they logon to the server (as I use mandatory profiles). This soon starts to chew up even large system drives. None of the normal methods of clearing the AppV cache empty this area. In fact the only command I found that did was SFTMIME /UNLOAD. Granted you could write a script to manually delete these files, but I wanted to use a supported method.

Using SFTMIME to unload all the apps turned out to be easier said than done due to the number of parameters that need to be sent and all the annoying spaces in file paths and application names. Anyway I wrote a really convuluted process which works great and thought I would share.

http://dl.dropbox.com/u/13464150/UnloadAppVCache.zip

Show Control Panel in Start Menu using Registry

If you are using roaming profiles, or even better mandatory profiles, you can set the Control Panel to appear or not appear in the Start menu for all users by editing the following registry key in the NTUser hive:

[HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Start_ShowControlPanel

1 = Show Link
0 = Hide

We use Appsense to set this key on logon for specific users on specific servers.

Changing the Primary Domain DNS name of this computer to "" failed.

We have been hitting an error when adding Windows 7 and Windows 2008 R2 machines to our Windows 2003 domain, specifically:

.

.

.

.

This issue does not affect older versions of Windows and does not appear to stop the computer from successfully joining the domain. I looked into the c:\windows\debug\netsetup.log and found the Windows 7/2008 R2 perform an additional number of steps at the end of the domain join, things that previous OS versions have not done and the following error is shown:

NetpLdapBin:ldap_bind failed Server:81: Server Down

I am yet to discover exactly what these additional steps do, but it was easy to spot the problem. Throughout the domain join the server contacts the domain controllers using the DC FQDNs. In this last section it attempts to contact the domain controllers using the netbios name, which fails as we do not apply domain suffixes to our servers and workstations using DHCP - we use the standard DNS devolution and setting to apply parent DNS names. If you do use DHCP to apply DNS suffixes you more than likely will not see this issue. If you don't you can work around the issue by adding a manual DNS suffix for your domain before your domain join and then remove it again afterwards (this is how we are working around it for now). Or you could just ignore it as I cannot find any negative side affects.

Microsoft have confirmed this as a bug in Windows 2008 R2 and Windows 7 but have not yet committed to a fix date as they see it as low priority (as it does not break anything). I have requested a KB number from MS, which I will post ASAP.

Your Out of Office settings cannot be displayed because the server is currently unavailable. Try again later.

There are loads of blog entries about this error and numerous causes. It could be that autodiscovery is not working correctly, that the OOF URL is configured incorrectly, permissions are wrong on the CAS servers etc.... I'm not going to go into detail here as there are loads of blogs and articles about this.

Our situation was slightly different to anything I could find. OOF works just fine for our users, however as Exchange administrators we could not set other users OOF when using Outlook 2007, we got the error "...the server is unavailable...". We also found that we were unable to login to other users mailboxes using our Exchange admins accounts using OWA, which was the other way we used to set OOF for absent users. The only way we could still set OOF for end users was to use Outlook 2003, but this is no longer supported on our campus, so we needed another way. This prompted me to get to the bottom of this problem, so we as system admins could again easily set end users OOF.

The one thing that was obvious is that this was a problem that only happened when connecting via the CAS servers. We could login to mailboxes just fine using MAPI. Therefore there had to be something different about the way the CAS servers authenticate users against mailboxes. It is worth mentioning at this point that we had confirmed that our admin accounts were listed as having Full Mailbox Access to all mailboxes in ESM. We soon discovered that the server is unavailable error is a generic error and happens regardless of what error is actually returned by the server. Having tried the URL of the OOF within IE we saw that it was actually an access denied error that was being returned by the CAS server, not a service unavailable error. We were stumpted as our admin accounts had full access!

With some testing I noticed that some of our several thousand mailboxes did allow us to set OOF as admins, but the vast majority did not. The question was why. I then started playing with Full Access permissions and found that any change whatsoever to the Full Access permissions using ESM or the shell suddenly made OOF work for our admin accounts. This is where Microsoft came in as I was stumpted. It turned out that this is apparantly an expected issue that Microsoft have documented very poorly. It is a result of the split permissions model in Exchange 2007. When connecting to a mailbox using a CAS server (as OOF does in Outlook 2007), the CAS server reads the MSExchangesecurityDescriptor from AD. By default this is truncated and incomplete. To cut a long story short, Microsoft no longer support automatically inherited AD permissions to mailboxes, although you will see the permissions using ESM and they will work using MAPI connections. I find this utterly baffling, but it is what it is. In order to resolve this you need to make a change to the mailbox permissions using the shell or ESM. This causes Exchange to rewrite the MSExchangeSecurityDescriptor in AD and suddenly everything works. A couple of methods and further info:

add-mailboxPermission -identity -accessrights:fullaccess

get-mailbox -server Add-MailboxPermission -User -AccessRights FullAccess

http://technet.microsoft.com/en-us/library/aa996343(EXCHG.80).aspx

http://support.microsoft.com/kb/310866

MapiExceptionNotAuthorized in Exchange 2007

I thought I would share with everyone an issue we had with mail delivery to Public Folders in Exchange 2007. We were receiving the following error:

#550 5.2.0 STOREDRV.Deliver: The Microsoft Exchange Information Store service reported an error. The following information should help identify the cause of this error: "MapiExceptionNotAuthorized....

This happened for some staff, but others could deliver messages just fine. Also external users i.e. Hotmail could deliver messages to the PFs without issue.

You would imagine then there must be a deny rule somewhere for a specific group of staff, or there was something wrong with the permissions on the PF. Numerous tests and checks proved this to not be the case.

Fortunately a pattern started to emerge with the people having the problem i.e. they were all in the same faculty and members of specific groups. Further testing proved that if a user was a member of a few groups their messages/emails would be denied to ALL PFs. However the groups were not mentioned anywhere in the PF permissions.

We even created new mail enabled PFs and gave everyone full control with no denies... still no luck. After a bit more thinking we figured that it must be that Exchange is having trouble reading the group membersip. We soon found that the OUs containing the problem groups of which the problem users were members, had inheritance switched off and hence had not picked up the new Exchange 2007 permissions when we installed EX2007. They still allowed the old Exchange Enterprise Servers group acccess which worked for EX2003, but no access was in place for the EX2007 Exchange Servers group. The OUs had also had read permissions removed for Pre-Windows 2000 (Everyone) and Authenticated Users. Therefore Exchange was denying the user access as it could not fully recurse the users ACLs. I guess this is secure by default in action, although it seems like a bit of an inefficient design to me.

I hope this saves someone a bit of time as it took us ages to get to the bottom of it.

Exchange 2007 Outlook Web Access Old Passwords

Weird one yesterday. We had a customer who had fallen foul of a phishing email and entered their username and password in a web form. Surprise surprise their account was compromised and used for sending a huge amount of SPAM. As soon as we became aware of the problem the user changed their password. Because the spammer had already established a connection as this user the password change did not affect them and they carried on. No major surprises there. We had to lapse the account (disable) for the connection to be dropped (I wish Microsoft would provide a tool for checking/closing active OWA/IMAP sessions in Exchange). The surprise came when we found the user could continue to login to OWA/IMAP using their old password, although it could not be used for any other resources. With some investigation it seems that once a user has authenticated to a CAS server with a password, as long as the connection remains active (and for some time after) the old password can still be used to authenticate (open new connections) to OWA/IMAP. This is alarming in my opinion. The most alarming thing is that all connections can be closed and you can still login using the old password (although I don't know for how long).

This issue is per CAS server. We usually have two, so this issue would not be as obvious normally (as the server the user logged into using the old password is the only server that will allow logins to continue using the old password).

I am going to log a urgent call with Microsoft about this. For info we are using Exchange 2007 SP1 RU5 on one front end and Exchange 2007 RU5 on all backends. The other front end has recently been upgraded to RU7, but the issue remains.

Anyone else seeing this?

Support for Citrix Secure Gateway

08/07/09

We currently run Citrix PS 4.0. Due to support running out at the end of this year we have been looking at upgrading to XenApp and have run into confusion over whether Citrix Secure Gateway is still supported or if we need to switch to using Access Gateways. It seems that the general confusion about support for SG is fairly widespread, perhaps because Citrix really want customers to start using Access Gateways. Anyway, we did not need all the benefits that AGs have over SGs so through our helpful support people we put the question to our Citrix account manager. It took a while to get an answer (the confusion does not seem to be limited to customers), but the good news is that Secure Gateway support is directly linked to support for XenApp. Therefore SG 3.1 will be supported as long as XenApp 5.0 is supported. The following Citrix article explains a little more:http://support.citrix.com/article/CTX110115
Although this article is 3 years old we are told by Citrix that it is still valid.

With this info we can get on with our XenApp upgrade!

Appsense - Internal Server Error

01/07/09

I have been having fun trying to get Appsense 8.2 to work following the database being accidentally deleted by a colleague. Despite the Management configuration utility providing a facility to create a new database it refused to use its new database and kept trying to use old settings. I gave up and reinstalled.
The reinstall did not fix the initial problem I was seeing with loading the Management Console. Basically it reported that the server returned HTML instead of XML. When I went to the Management Server website directly it returned a 501 error, specifically related to custom HTML error pages using explicit paths. I opened all the web.config files (there are about six of them under the Appsense installation directly) and deleted the CustomErrors sections. All then worked.
I have no idea why and when this issue started. All I can imagine is that it is related to the installation of Windows 2008 SP2.

02/07/09

The very efficient chaps at Appsense spotted this blog entry and sent me the following link:

https://www.myappsense.com/content/knowledgebase/solutionDetails.aspx?sid=50120000000EW3dAAG

You will need a MyAppsense account to get to this, but as an Appsense customer you should have one. That will teach me for not checking the knowledge base articles before upgrading!

Anyway the issue is related to a Windows 2008 SP2 security change. The advice given in the article as the same as the way I fixed and problem. Importantly it does state that you should not change the %PROGRAMFILES%\AppSense\Environment Manager\Personalization Server% and PROGRAMFILES%\AppSense\Performance Manager\Central Statistics\Incoming web.config files (I better go and fix mine). It also states that the issue is fixed in v8 SP2, but I don't seem to be able to download that just yet.

Now onto why my upgraded v7 App Manager config causes my server to go totally nuts and stops a number of core services from starting and even entirely kills the network connection! I quess I'll be creating that from scratch :-).

Exchange 2007 IMAP RFC822.SIZE and Pine/Alpine

A common problem with Exchange 2007 IMAP when used with Pine/Alpine is alerts indicating that a message has shrunk. What is happening here is that Pine is retrieving the RFC822.size from Exchange, downloading the message and comparing the real message size with the size Exchange 2007 provides. Sadly there often is a huge discrepency, sometimes by as much as a factor of two. Interestingly Pine only checks for size decreases in case of data loss during copy hence you only see this message appear on some emails, not all. If Pine checked for message decreases and increases you would see it for pretty much all emails.

Microsoft have so far explained that the size returned by Exchange prior to Exchange 2003 was based on the MIME message stored in the STM database. As the STM database no longer exists in Exchange 2007 the RFC822.size is calculated based on the MIME skeleton and the original MIME message size. This is done for performance reasons. I have asked Microsoft for clarification as to why the original MIME size of the message is vastly different to the regenerated MIME message and am waiting for clarification.

There is an Alpine code change that will supress this message (if you are happy to lose the safety check), or you can apply a change to Exchange on either a server or on individual mailboxes. The setting is nothing secret but documentation is very scarce. It is worth mentioning that making this change has a performance penalty as it forces Exchnage to regenerate each message as MIME and then send the size of the regenerated MIME message every time a message size is read.

For the server:

Set-ImapSettings -EnableExactRFC822Size:$true

For each user:

Set-CASMailbox "username" -ImapUseProtocolDefaults:$false -ImapEnableExactRFC822Size:$true


Although this solves this particular problem, sadly other issues persist with Pine and Exchange 2007 like Pine crashing when opening messages with Digital signatures and Pine not handling multipart messages correctly. It seems that although these issues only appear in Pine/Alpine (and perhaps Mutt), it appears to be Exchange that is failing to follow the RFC standards (and Pine is a stickler for standards!).

I'm sure we will get there soon!

Exchange 2007 SP1 RU5 - IMAP Error 4999

Hi,

Like many other people we have been suffering from our Exchange 2007 SP1 RU5 IMAP service constantly falling over with the following error:

Watson report about to be sent to dw20.exe for process id: 6848, with parameters: E12, c-RTL-AMD64, 08.01.0336.000, M.E.Imap4, M.E.D.Common, M.E.D.G.OutboundCodePageDetector.AddText, System.ArgumentNullException, 3e79, 08.01.0336.000. ErrorReportingEnabled: False

The good news is that we have put a stop to this by isolating it to a specific user.

There are many records online about this being a known issue, which it seems is indeed the case and we have received the fix from Microsoft (which we intend to try on the 27/02) - KB960292. I will post how this goes. The problem relates to a null ID being presented during login that the IMAP service should ignore, but it fails instead.

Anyway, what I wanted to share is that we have isolated this issue to the Sea Monkey 1.1.14 client. All three installations we know of are causing this issue and we have worked around it temporarily by preventing the users from logging in using IMAP (they are using OWA temporarily instead).

Good luck if you are experiencing this problem.

Rob

Increasing Redirect to Voicemail Timeout on O2

When I received by lovely new HTC Touch HD I found I kept missing calls as there was a slight delay between the caller calling and the phone starting to make a sound. I contacted O2 and they told me to run the following command :

**61*901*10*??#

?? is the delay you want in increments of 5 up to 30. I went for:

**61*901*10*25#

Works a treat.

I hope this saves someone a bit of time.

This is the home email address of this recipient. It cannot be removed

It has been a while since I posted, but I came across a nuisance error this morning: "This is the home email address of this recipient. It cannot be removed". The address that could not be removed was not the primary address and what's more this was a mailbox, not a contact, so I could not just delete it without disrupting the user. I needed to remove the rogue address as it had been created in error and was a domain that was not managed by Exchange. Anyway, I launched ADSIEdit.msc, found the attribute TargetAddress (http://msdn.microsoft.com/en-us/library/aa487600(EXCHG.65).aspx) and cleared it. I could then go back to ADUC and remove the rogue address. After about 20 minutes mail started to be delivered to the mailbox once again.

Using the Safari Browser with the Citrix Web Interface 4.0

Citrix provide a very helpful article at http://support.citrix.com/article/CTX104367 describing how to customise the Citrix Web Interface 4.0. to support the Mac client on Safari. This works well, but it is not the whole job as when the user logs off and back on again, they will find their client is set back to Java. It also does not present the user client installation prompts in the message centre until they are logged on.

It is fortunately very simple to complete the job. Follow the steps in the Citrix article and then do exactly the same for the following files in the auth folder as you did for the same named files in the site folder: include.cs, embed.cs, install.cs.

Works a treat. Obviously all changes should be tested in a dev environment first and don't forget to read Citrix's disclaimer on the webpage linked above.

Windows Live Mesh

I recieved my invite to Live Mesh today and found it would not install and reported that I should check my network settings: "Installer encountered errors: Please verify your network settings and attempt to reinstall".

Well all was fine with my network settings. I tried setting my locale to US as suggested on some site and ensured that UAC was switched on. I then tried changing my auto proxy configuration script to a hard coded proxy (in IE connection settings) and Live Mesh then installed. So if anyone else sees this error and you are using an automatic configuration script for your proxy, that is why.

Hopefully Microsoft will fix this at some point.

SPSS and Appsense Environment Manager

I am having trouble with SPSS 15 running on Citrix Presentation servers which also has Appsense Environment Manager running. Basically, Environment Manager kills the SPSS processor. I can reproduce this consistently and fix the problem by either disengaging the EM process, removing the EM DLLs or simply removing any applied EM policies.

I have had a call open with Appsense about this for a few weeks. The only suggestion they have made so far is to upgrade to the most recent version. I did this (7.2.227), but it made no difference.

Currently I am trying SPSS 16.0, but not having much luck as our license for SPSS 16.0 is not authorised for use on a terminal server......... Hopefully I will have a call from SPSS soon to establish how I can run this test.

Has anyone seen this issue?

I will keep this post updated, but it looks like we are going to have to switch of Environment Manager on our Citrix servers and live without the good things that it does.

SoftGrid 4.1 - Desktop Refresh Times Out - Error 10000005

I've had issues with SoftGrid today with all Desktop Refreshes failing and no applications launching. Unfortunately this happened while I was rebuilding one of the VAS servers so I wasted a lot of time trying to trouble shoot issues that could have been caused by removing this server.......

The errors I was seeing in the sftlog.txt file when trying to launch applications were:

[03/11/2008 08:00:28.370 AMGR WRN] {hap=1:app=CorelDRAW X3 13.0.0.739:tid=4FC}The SoftGrid Client lost contact with a server and entered disconnected mode.
[03/11/2008 08:00:28.385 JGSW ERR] {hap=1:app=CorelDRAW X3 13.0.0.739:tid=148C:usr=srvrjh}The SoftGrid client could not connect to stream URL 'rtsp://appstreaming.leeds.ac.uk:554/cdrawtst/cdrawtst.sft' (FS status: 1600190A-00000120).
[03/11/2008 08:00:28.385 SWAP ERR] {hap=1:app=CorelDRAW X3 13.0.0.739:tid=148C:usr=srvrjh}The client was unable to connect to a SoftGrid server (rc 1600190A-00000120)
[03/11/2008 08:00:28.432 TRAY ERR] {tid=C88:usr=srvrjh}The SoftGrid Client could not launch CorelDRAW X3 13.0.0.739.

An unexpected error occurred. Please report the following error code to your System Administrator.

Error code: 41112E-1600190A-00000120
This turned out to be nothing to do with the VAS rebuild and was actually associated with the provider policy. It seems that SoftGrid does not use native Windows authentication but instead employs LDAP. In our architecture LDAP often causes issues. We have two domains, a forest root and a child. The child domain is first in the alphabet.

Anyway, we performed some AD upgrade work at the weekend and the one domain controller in the child domain that the VAS servers could contact was offline (in case we needed to revert back the domain). We accepted the fact that users in this domain would not be able to authenticate to the VAS servers during this period, as we have no softgrid users in that domain at present. However what we did not anticipate is that because a group of users from the child domain was defined in the provider policy, SoftGrid would time out trying to contact the domain and it would break all desktop refreshes and all applications (that were not 100% pre-cached).

Microsoft states the issues we were seeing are related database problems, but I would suggest that before you do anything with your databases that you check your provider policy and look for any groups that have not been properly resolved.

ISA 2006 Custom Login Page

I have a couple of custom login pages on ISA 2006 to fit with company branding. This all works well with one problem. When a user enters an incorrect username or password, every now and again the user is dropped back to the default ISA login page. This does not break anything and the user can carry on to login ok, but it looks a bit daft and is very confusing for the end user. I may well be logging this with Microsoft, but I would rather not as it seems like an issue that Microsoft are going to want a lot of information on and because it is very intermittent it could take a lot of time (of which I don't have much). If anyone has found a work around/fix for this I would love to know. Please post to this blog entry. I'll keep it updated if I get anywhere with it.

Softgrid Documentation

Are you looking for the Softgrid 4.1/4.2 Documentation/Softgrid Admin installation guide? Well it is well hidden and oddly not linked from the Softgrid home page and you will be hard pressed to find it on Google. Anyway, it is here: http://support.microsoft.com/kb/940163

I hope that helps save someone a bit of time hunting around.

Master Site Directory in Sharepoint 2007 Error

I ran into an error when trying to assign a master site directory in MOSS 2007 Central Admin:

This not a valid site directory. Specify a URL to a site that is using the site directory template.

I checked that the URL was valid and that it was pointing to a Directory Site. I even created a new directory site and tried that with no luck.

I worked out that if I set the default public URL to be a simple name like site, instead of site.domain.co.uk, the master site directory page accepts the entry and it all works. However this is no good as we need a proper FQDN as the default public URL (and changing it back after setting the MSD breaks the MSD functionality).

I have a call open with Microsoft through ESCUK about this. This call has been dragging on for a long time and somehow Microsoft have not been able to reproduce the problem.

I'll keep this post updated as and when I hear something back from Microsoft. I would be very interested to hear if anyone else is seeing this problem so I can feed back to Microsoft. Thanks!

07/01/08

Microsoft have finally reproduced this problem and have acknowledged it as a 'possible bug', as such it has been escalated. No news as to a fix yet.

23/01/08

Today I had a call from a developer at Microsoft who has been looking through the code used by the Master Site Functionality and established that it first checks for the existance of the site in the configuration database. This is interesting because apparently if it does not find the exact URL in the config database it will reject it. This means that if you use a different default AAM to the URL you used when creating the web application that hosts your MSD, the lookup will fail. The only way I know of to fix this is to extend your web application and use the URL of your default AAM as the URL for your new IIS site and set this extended web app to use a different zone (i.e. Intranet). The default AAM URL will end up the default AAM for two different zones and will now appear in the configuration database (as it is added by Central Admin when you use it to extend the web app). This is not pretty and I don't advise you go ahead with it in the production environment without taking advice from Microsoft.

Fortunately our default AAM was also the URL that was used to create the original web application used to host the MSD. Therefore the work around above is not appropriate. Back to the drawing board......

Quick thought...... if using NetBios names fixes the problem, what could be happening differently for FQDNs. Perhaps a proxy issue. However I have made sure that our proxy is configured to be disabled for the application pool and service accounts. However each web application's web.config file by default sets the proxy to auto=true. The developer at Microsoft suggested changing this to false for the Central Administration web application. That did the trick! We now have a full functional master site directory. It was a very long time coming for a simple solution, but a good learning experience.

To make this change go to C:\Inetpub\wwwroot\wss\VirtualDirectories\****, where **** is the port number of your Central Admin site. If you are not sure which is the right virtual directory open IIS Admin, right click on the Central Admin site and choose Explore. Right click in the white space to the right and select properties to get the folder and path. Open the web.config and locate the following:

(system.net)
(defaultProxy)
(proxy autoDetect="true")
(/defaultProxy)
(/system.net)

Change to:

(system.net)
(defaultProxy)
(proxy autoDetect="false")
(/defaultProxy)
(/system.net)

You will also need to do this for any web applications that you want to create Site Collections from within a Site Directory page (and make use of the Master Site Directory feature). Hhowever if you do this you may want to use something more like below so that web parts like RSS readers can connect to external feeds.



This adds exceptions for *.domain.local.com and 198.168.*.*

I hope this saves someone a lot of time!