MDs suggestion resolved the issue for me.
msiexec.exe /i CiscoJabberSetup.msi CLEAR=1 UPN_DISCOVERY_ENABLED=false TFTP_FILE_NAME=jabber-config-chat-only.xml
Note:
1. Remove the spaces in MD's command between UPN_DISCOVERY_ENABLED = false - it should be
UPN_DISCOVERY_ENABLED=false
2. The username was still present UNTIL I reset Jabber one final time. Resetting it WITHOUT using MD's UPN switch would NEVER delete the username.
3. I'm mapping my Jabber Chat Only configuration to the file name "jabber-config-chat-only.xml which is shown here:
<?xml version="1.0" encoding="utf-8"?>
<config version="1.0">
<Options>
<Start_Client_On_Start_OS>true</Start_Client_On_Start_OS>
<STARTUP_AUTHENTICATION_REQUIRED>True</STARTUP_AUTHENTICATION_REQUIRED>
</Options>
<Policies>
<Telephony_Enabled>false</Telephony_Enabled>
</Policies>
</config>
With that set of switches, I disable telephony (this is a chat only deployment), I configure the client to auto-start, BUT most importantly, I prevent the password from being cached forcing the end user to manually enter the password to authenticate.
We sync CUCM to AD every 8 hours. When an AD user passes the 60 day password reset policy, they use Ctl-Alt-Delete and modify their AD password for security compliance purposes. They are then able to login to their PC on the network and Jabber auto-launches with cached credentials (old password).
At this point - AD has their NEW password and CUCM still contains their OLD password because the sync interval is 8 hours. Because their username and password are hard-coded into Jabber, what I've found is often users forget to modify their Jabber password and Jabber will continue to authenticate successfully against CUCM because it contains their OLD password until the 8 hour sync interval has expired. Once AD - CUCM sync has occurred, their Jabber account locks out their AD credential because the CUCM db has their NEW password but they have not modified the previously cached password in their Jabber client.
