I’m working for a while on a XenApp 6 environment. While designing the infrastructure, we decided to stream applications to XenApp servers. To secure the application profiles repository, we decided to implement DFS with 2 targets and DFS-R for replication. The following figure shows how it works :
We recently profiled Office 2007 using the Citrix Best Practice. By the way, don’t forget to include MSVCR80.dll file as mentioned in the step by step. Then, we stored the newly created profile in the DFS store.
In our environment, Office is launched by another application (streamed as well) to generate Excel reports. Since our first tests, we faced erratic failures. Sometime it works, sometimes it doesn’t !
I quickly suspected DFS replication. By manually specifying DFS target, I saw that tests are successful when application is launched from a specific target and all tests fail when using the other target. The little Power Shell script below help me to find that only one file differ between the 2 profile’s replicas, which is OPA12.BAK.
$dir1="\\SERVER2\share" $dir2="\\SERVER1\share" $d1 = get-childitem -path $dir1 -recurse $d2 = get-childitem -path $dir2 -recurse compare-object $d1 $d2
Indeed, DFS-R excludes some file types from replication. Take a look on Technet to know how to change the rules. Not so difficult to resolve the problem but not easy to figure where it was.
I encountered exactly the same problem 4 years ago, while trying to synchronize Office 2003 installation files. The Office’s sources contains necessary BAK files too.
I just want to render thanks to Microsoft for that. The more you make simple things complicated, the more customers think I’m smart !