Hi David,

You also have to take into account that there is an LDAP path associated with the destination queue that will still point to the development domain.

If the path in the development domain and the production domain are not exactly the same errors will occur.

Unfortunately you will have to use K2.net Studio in the production environment and map the destination queues to the groups in the production domain in order to update the LDAP path. :?

---

Thanks Conrad.

I was afraid of that. Is there a way in the code for the destination rule where you could, say, pick up a string table value and use it to configure the LDAP path dynamically?

Thanks

---

Hi David,

The LDAP path is created when the destination queue is created. There is also no way to get to it in code at design time.

In the code-behind of the destination rule the only reference made to the queue is the name. This name is used at runtime to retrieve the LDAP path from the database.

I cannot think of any workaround for what you want to achieve.

If anyone has an idea let us know about it please

---

Hi Conrad,

Thanks for that. I'll have to think of something else. The problem is that we have 3 different domains; dev, UAT and live. It seems unrealistic to have to open the K2 solution in each environment and recreate the destination queue. I am starting to think that maybe we could create backups of the _DestQueue and _DestQueueUser tables for each environment and reinstate them in each K2 database after an export (assuming the definitions of the queues do not change of course). Do you know what the implications of this approach may be? Is the DestQueueUser table refreshed by the periodic (10 minute?) refresh from active directory?

Surely other developers must have hit this issue and come up with a workaround that doesn't involve re-defining the queues each time you do a deployment to another domain?

Cheers

---