Thank you to all who attended the event last week at Fortrust where we discussed how we help clients with the DR planning, implementation ongoing management. We discussed premise solutions and DRaaS (DR to our cloud infrastructure) solutions as well. Thanks also to out partners: Fortrust, Faction and Zerto for participating. Many of you have asked for the presentation and I’ve posted it here for your convenience.
Not only do folks need to worry about the Windows 2003 systems that support the business applications they use, but also be on the lookout for “embedded systems” that may be lurking within your environment that you don’t really consider application server, e.g., phone systems, alarm systems, management systems, etc…
If you’d like some help in discovering your Windows 2003 exposure please reach out to us sooner rather than later. July will be here before you know it and those who plan early will get the resources that are available to assist. Those who don’t….won’t.
The importance of deleting old stuff—another lesson from the Sony attack | Ars Technica – http://arstechnica.com/security/2015/01/the-importance-of-deleting-old-stuff-another-lesson-from-the-sony-attack/#p3
A good blog post on a problem we’re going to face here shortly in the Cisco UC world. Time to prepare… If you need help, give us a ring.
The coming storm is here:
The public CAs are no longer signing certificates with subject alternative names (SAN) for internal server names — (https://www.digicert.com/internal-names.htm).
An internal name is a domain or IP address that is part of a private network. Common examples of internal names are:
Any server name with a non-public domain name suffix. For example, http://www.contoso.local or server1.contoso.internal.
NetBIOS names or short hostnames, anything without a public domain. For example, Web1, ExchCAS1, or Frodo.
Any IPv4 address in the RFC 1918 range.
Any IPv6 address in the RFC 4193 range.
Why do we care?
Jabber authenticates TLS encryption using certificates for services from CUCM, CUC, IM&P, etc. Historically these have typically been deployed with IP addresses only, or internal domains (e.g. domain.local, etc.). Because of this you can no longer get a certificate for the Expressway-C box that has SANs with IPs or internal names. Jabber requires valid certificates for login now.
See the Expressway Certificate guide p.7 for Expressway-C here – http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/expressway/config_guide/X8-2/Cisco-Expressway-Certificate-Creation-and-Use-Deployment-Guide-X8-2.pdf
Without a certificate with proper SANs, Jabber will either throw an invalid cert error, or will completely deny login to UC services.
Using Collab Edge MRA, Jabber authenticates to the Expressway-E server and uses it’s certifciate. Internally Jabber communicates directly with each component.
Dealing with the issue for Collab Edge MRA
Basically we have two options to work around the SAN issue:
1) Change the domain name of the UC components to a valid public domain name that the public CA will sign for. This doesn’t mean the server has to be accessible from the internet by any means or that it is an existing domain name your company is using.
Option 1a: Deploy a new public domain name for UC services internally. For example if your domain name was domain.com you might see if domain.info or domain.net or something similar is available to register and use as the internal UC domain name. The domain wouldn’t need to resolve externally at all.
If you do this, then you need to take in to consideration that the MRA deployment becomes a multi-domain (or split-domain) deployment which requires some special treatment like the VoiceServicesDomain option. (See my previous post about multi-domain deployments.)
Configuration example here – http://www.cisco.com/c/en/us/support/docs/unified-communications/expressway-series/117811-configure-vcs-00.html
Options 1b: The seemingly easier deployment would be to just match your public domain name that you use for email (e.g. domain.com) for your UC components (not suggesting all internal servers — file, print or otherwise, need to be in this domain). This makes services discovery nice and clean.
The challenge to this method is usually the need to deploy a split DNS for internal and external name resolution. (The internal DNS server also serving the domain.com zone and having the A records for internal services, where the external DNS server have A records for external services.)
2) Create certs using your own internal CA, like Microsoft AD Certificate Services, or OpenSSL, etc. There are no restrictions on SANs with your own certificate server. I detail how to use OpenSSL to sign certs in an earlier post.
The major constraint to this deployment option is the need to get the trusted cert from your CA server on to all devices that will use MRA. AD does it for your Windows machines automatically, but mobile devices will need to have this certificate installed. Using an MDM like Meraki MDM (freemium service) or others to push the certificates would be the way I’d attempt to deploy the certificates
The Implications of changing the domain name of CUCM/CUC/IM&P
Anyone who’s attempted to change the hostname of a CallManager knows the trainwreck and ensuing TAC calls that will ensue.
I’ve personally not tried to change the domain name of a CallManager or CUC in recent memory, but doing so for IM&P/CUP is relatively straightforward.
The hostname/domain name change procedure is here for CUCM/IM&P – http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/install/10_0_1/ipchange/CUCM_BK_C3782AAB_00_change-ipaddress-hostname-100.html
The name change procedure is here for CUC – http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/9x/upgrade/guide/9xcucrugx/9xcucrug060.html
I’d do this with a healthy amount of trepidation. 🙂
Give it a try: VMTurbo Download
From our internal blog.
Experienced this issue today. Apparently updating a word document with “track changes” can cause Word to error saying that the Macintosh HD is full. (Which it is NOT). http://answers.microsoft.com/en-us/mac/forum/macoffice2011-macword/the-disk-is-full-trying-to-write-to-macintosh-hd/8284db3c-bfa1-4aec-ad51-a97f5c134e48
Word for Mac 2011 keeps giving me the following message: “the disk is full trying to write to macintosh hd”, followed by a message saying that autorecover cannot save the file to the chosen location.
Handy article for environments doing NFS (NetApp, Ilio, Flex-IO, USX..) – http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2239
So true. I’ve got to go through my home and business office and get rid of all this old stuff as a resolution for 2015.