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?