Replacing the default https certificate in a java keystore

I have a JBoss server that hosts a bunch of web apps, and I needed to update the self-signed certificate that signs the https requests.
Step 1: find the keystore.jks file

[root@jboss ~]# find / -iname keystore.jks
/opt/jboss/domain/configuration/security/main-loadbalancer-group/keystore.jks

Step 2: backup the keystore.jks file, and remove the old "https" keystore. This won't affect the running JBoss services until you restart it.

[root@jboss ~]# cd /opt/jboss/domain/configuration/security/main-loadbalancer-group
[root@jboss ~]# cp keystore.jks keystore.jks.bak
[root@jboss ~]# keytool -delete -keystore keystore.jks -alias https

Step 3: generate a new private key with alias of "https"

[root@jboss ~]# keytool -genkey -alias https -keyalg RSA -keystore keystore.jks -keysize 2048

Step 4: generate a certificate request for "https"

[root@jboss ~]# keytool -certreq -alias https -keystore keystore.jks -file myjbossserver.csr

Step 5: copy the certificate request to the CA server
Step 6: set up your CA config file with the SANs you want. Use this as a guide: http://apetec.com/support/GenerateSAN-CSR.htm

[ccondry@ca:~]$ sudo openssl ca -config ./myjbossserver.cnf -in myjbossserver.csr -out myjbossserver.crt

Step 7: copy the signed certificate and the ca's public certificate back to the jboss server
Step 8: import the ca certificate (mine is ca.crt) as a trusted certificate, with the alias "myca"

[root@jboss ~]# keytool -import -trustcacerts -alias myca -file ca.crt -keystore keystore.jks

Step 9: convert the certificate to DER so that keytool can import it

[root@jboss ~]# openssl x509 -outform der -in myjbossserver.crt -out myjbossserver.der

Step 10: import the new "https" certificate, in DER format

[root@jboss ~]# keytool -import -trustcacerts -alias https -file myjbossserver.der -keystore keystore.jks

Step 11: restart your jboss server for the changes to take effect! (note your jboss service is probably not "jboss", so just replace that with your service daemon script name)

[root@jboss ~]# service jboss restart

Can't uninstall Exchange 2013 or install another Exchange server version in current domain

I was stuck with a broken Exchange 2013 installation (brand new, too - never could fix the 'emails stuck in drafts folder' issue). I also couldn't uninstall Exchange 2013, because I couldn't delete all the mailboxes in it (access to the error message was denied...). And, once you install Exchange 2013 in your domain, you can't install another previous version in the same forest.

Fix: Open up ADSI Edit, connect to your domain, and choose 'Default naming context'. When ADSI Edit has connected, look in the folder directly under "Default naming context [your.domain.com]". It is named with your domain's distinguished name. Delete these folders:
CN=Microsoft Exchange Security Groups
CN=Microsoft Exchange Security Objects
Now change the ADSI Edit connection from 'Default naming context' to 'Configuration' and look in the folder directly under it. Go to the "CN=Services" folder, then delete these folders:
CN=Microsoft Exchange
CN=Microsoft Exchange Autodiscover

You'll also have to delete some user accounts, but this was the step that took me the longest to figure out. Thanks to this site for the info: http://blog.dargel.at/2012/11/20/complete-remove-exchange-2013-using-adsiedit/

Attempted to send call to agent: (ID: ), on peripheral: (ID: ), who has no device target.

If you receive an error like this:

Attempted to send call to agent: ccondry_0 (ID: 5050), on peripheral: CUCM_PG (ID: 5000), who has no device target.

Then you need to add the Routing Client in question to the Agent Targeting Rule you have set up for the agent device. Here is a screenshot of the button to add more routing clients to an existing Agent Targeting Rule:

Fix "Unknown" CLID on CUCM phone

I'm trying to get an Android app on the Cisco DX series phones to pull the caller ID field of the current call. If the call comes through UCCE, the caller ID number (or string, in this case) comes through fine. If the call goes directly to the extension, the expected caller ID is displayed while the phone is ringing, but then displays "Unknown" as the caller ID at the top of the call screen - and this is what my Android app is seeing.

To fix this, I had to turn off all options except "Caller Number" in the "Forwarded Call Information Display on Device" section of the device's line settings. Here's a screenshot of the settings on a device:


and here's where you would change it in the auto-registration template:

Fix eGain v11 services and instances stuck in 'Starting' state

eGain v11 will sometimes get stuck its service instances stuck in a 'starting' state where you can't manually start or stop them, and they remain in this state even after reboot (because the interfaces is just reading a database field, not the actual state of the service). Here's an SQL statement to set all instances in the 'starting' state to the 'stopped' state:

UPDATE [eGMasterDB].[dbo].[EGPL_DSM_INSTANCE] SET STATE = 4 WHERE STATE = 6

If you have a system service (as opposed to an instance of that service) that is stuck, use this instead:

UPDATE [eGMasterDB].[dbo].[EGPL_DSM_PROCESS] SET STATE = 4 WHERE STATE = 6

Obviously, if your eGain Master database has a different name, you'll need to change that. You can also limit this down to a single service or instance by changing the WHERE STATE = 6 to narrow down the search using the instance or process name/id. Just have a look at those tables to see what you need to use. For reference, here are the states:
0 = Undefined
1 = Error
2 = Waiting
3 = Running
4 = Stopped
5 = Undefined
6 = Starting

Where is my T1/E1 card?!?!

In Cisco IOS, you have to use the "card type" command first, before "interface controller" will even show up as a valid command.

I'm using a UC520 box with a built-in T1/E1 port that is labelled "0/3" on the exterior of the physical device, so this was the command that worked for me:

card type t1 0 3

You'll then need to follow up with something like this:

isdn switch-type primary-5ess

!

network-clock-participate wic 3

!

controller t1 0/3/0
 framing esf
 linecode b8zs
 clock source line
 pri-group timeslots 1-24

!

Reference: http://www.cisco.com/c/en/us/td/docs/routers/access/interfaces/software/feature/guide/vd-t1e1_vwic3.html

Default ICM Superuser Password

ICM comes with a 'superuser' account that controls Configuration Manager, specifically the Application Object Filter. The default password:

password

You must change this password in Configuration Manager's Options (in the File menu). There is no installation step that defines this password.

Credit: https://supportforums.cisco.com/discussion/11664641/icm-application-object-filter-password