While going through some lab material re: name resolution basics and options on Microsoft Server 2008 R2, I hit some hurdles while trying to enable Network Discovery.
Under Network and Sharing Center | Advanced sharing settings, I was not able to even have the radio button stay checked until I confirmed the following services were started:
SSDP Discovery
UPnP Device Host
Function Discovery Resource Publication
Function Discovery Provider host
Link Layer Topology Discoverer Mapper
Even then, the results of navigating to Start | Network provided a blank screen. There was no warning that Network Discovery was not enabled, but there were no results either.
The last step was starting the service:
Computer Browser
It makes sense in hindsight, but the Microsoft curriculum might associated with my study (and likely yours) is a little lacking.
Diary of technical happenstance, simple Internet accessible scratchpad, and brain dump to save myself later
Monday, February 11, 2013
Sunday, February 10, 2013
MS Server 2003 Internet Explorer Enhanced Security Configuration
Given this MS Windows 2003 server was a lab server and I just wanted to eliminate the chance of this security feature from stalling or preventing me from doing lab work, I simply chose to uninstall it. It seems there is no other more elegant method to disable the feature or stop the associated security processes other than actually running an uninstall process. This seems drastic, but at least it's easy...
Go to Start | Control Panel | Add or Remove Programs
Then, Add / Remove Windows Components
Then, uncheck the Internet Explorer Enhanced Security Configuration
- or to only remove the feature from Administrators group
Click Details
Then, uncheck For administrators groups
The uninstall is quite fast and doesn't seem to require a reboot.
Go to Start | Control Panel | Add or Remove Programs
Then, Add / Remove Windows Components
Then, uncheck the Internet Explorer Enhanced Security Configuration
Click Details
Then, uncheck For administrators groups
The uninstall is quite fast and doesn't seem to require a reboot.
Tuesday, January 29, 2013
Cisco UCCX silent monitoring 7925 phones via CSD
The documentation related to configuring CSD silent monitoring through Cisco UCCX using SPAN ports / port mirroring / network sniffing (vs. the traditional desktop / CAD method) is a little disjointed at this time.
I have had success implementing it where UCCX is running on a UCS C200 chassis, the agents are using 7925 phones and the network infrastructure are 3560 switches.
One element that needs to be addressed in this configuration, and that is not obvious in related UCCX documentation, is the need to set up promiscuous mode on the VMware switch. You can find details here, but basically find the virtual switch serving UCCX, click Edit | Security tab | Promiscuous Mode drop down menu | Accept. Without this, traffic sent to the C200 physical interface serving the virtual switch / UCCX server via port mirroring won't actually reach the server, as it is not addressed to the server. The virtual switch will drop it.
Another more obvious matter is setting the UCCX monitoring device to the server interface. In the current 8.5 release, having a seperate monitoring server or a seperate NIC for monitoring is no longer supported so your only choice is the single UCCX IP address. Go to your UCCX GUI | Cisco Desktop Administrator (upper right drop down) | Services Configuration | Multiline, Monitoring & Recording | VoIP Monitoring Device, and confirm that devices to be monitored by network SPAN methods have Desktop Monitoring disabled and Monitoring Service set to the IP address of your UCCX server. I have found that a Manual Synchronization of Directory Services may be in order at this point, and that restarting the Cisco Desktop VoIP Monitor Service through Cisco Unified CCX Serviceability might also force the issue a bit.
There are a million things to consider when setting up the network monitoring but a real simple example of one way to do it on a 3560 is:
! Monitor the voice gateway interface to "hear" all calls going off premise.
monitor session 2 source interface Fa0/1
! Monitor the CUCM server interface to "hear" all the setup and tear down information about the calls you are listening to traverse the gateway interface above
monitor session 2 source interface Gi0/1
! Send all the stuff you "hear" above to the interface that is dedicated to the UCCX server via the VMware switch you setup in promiscuous mode. NOTE: without the ingress variables, you may limit yourself to one way data transfer on that port, effectively disconnecting UCCX from the network (your configuration may vary).
monitor session 2 destination interface Gi0/2 ingress dot1q vlan 20
In my case, since I am only interested in monitoring 7925 calls going off premise, there is no need to deal with monitoring AP or WLC interfaces specifically. Your switch type and IOS version may also limit you to monitoring a limited number of interfaces / VLANs and a limited number of monitoring sessions as well, hence not monitoring the voice VLAN above. Don't assume this will work or applies everywhere. Do a little research on what is supported on your infrastructure and what is required by your solution before you dive too deeply.
I have had success implementing it where UCCX is running on a UCS C200 chassis, the agents are using 7925 phones and the network infrastructure are 3560 switches.
One element that needs to be addressed in this configuration, and that is not obvious in related UCCX documentation, is the need to set up promiscuous mode on the VMware switch. You can find details here, but basically find the virtual switch serving UCCX, click Edit | Security tab | Promiscuous Mode drop down menu | Accept. Without this, traffic sent to the C200 physical interface serving the virtual switch / UCCX server via port mirroring won't actually reach the server, as it is not addressed to the server. The virtual switch will drop it.
Another more obvious matter is setting the UCCX monitoring device to the server interface. In the current 8.5 release, having a seperate monitoring server or a seperate NIC for monitoring is no longer supported so your only choice is the single UCCX IP address. Go to your UCCX GUI | Cisco Desktop Administrator (upper right drop down) | Services Configuration | Multiline, Monitoring & Recording | VoIP Monitoring Device, and confirm that devices to be monitored by network SPAN methods have Desktop Monitoring disabled and Monitoring Service set to the IP address of your UCCX server. I have found that a Manual Synchronization of Directory Services may be in order at this point, and that restarting the Cisco Desktop VoIP Monitor Service through Cisco Unified CCX Serviceability might also force the issue a bit.
There are a million things to consider when setting up the network monitoring but a real simple example of one way to do it on a 3560 is:
! Monitor the voice gateway interface to "hear" all calls going off premise.
monitor session 2 source interface Fa0/1
! Monitor the CUCM server interface to "hear" all the setup and tear down information about the calls you are listening to traverse the gateway interface above
monitor session 2 source interface Gi0/1
! Send all the stuff you "hear" above to the interface that is dedicated to the UCCX server via the VMware switch you setup in promiscuous mode. NOTE: without the ingress variables, you may limit yourself to one way data transfer on that port, effectively disconnecting UCCX from the network (your configuration may vary).
monitor session 2 destination interface Gi0/2 ingress dot1q vlan 20
In my case, since I am only interested in monitoring 7925 calls going off premise, there is no need to deal with monitoring AP or WLC interfaces specifically. Your switch type and IOS version may also limit you to monitoring a limited number of interfaces / VLANs and a limited number of monitoring sessions as well, hence not monitoring the voice VLAN above. Don't assume this will work or applies everywhere. Do a little research on what is supported on your infrastructure and what is required by your solution before you dive too deeply.
Cisco Unity Connection SpeechView SMTP Tip
It's in the troubleshooting guide for Cisco Unity Connection Transcription / SpeechView, so this post basically serves as an easy to find note-to-self.
You can generate an email from Unity Connection to any address you'd like using the SpeechView stt-service alias to test SMTP routing from the CLI. The command is:
run cuc smtptest youremailaddress@yourdomain.whatever
The recipient should recieve a test email from the Unity Connection server, and a simple successful reply will be recieved and noted via CLI as well. This test appears to only be available if SpeechView has been configured, but also served nicely as a test where an administrator was having issues configuring Accept and Relay appropriately under Message Actions.
You can generate an email from Unity Connection to any address you'd like using the SpeechView stt-service alias to test SMTP routing from the CLI. The command is:
run cuc smtptest youremailaddress@yourdomain.whatever
The recipient should recieve a test email from the Unity Connection server, and a simple successful reply will be recieved and noted via CLI as well. This test appears to only be available if SpeechView has been configured, but also served nicely as a test where an administrator was having issues configuring Accept and Relay appropriately under Message Actions.
Wednesday, January 16, 2013
Cisco CUCM 7.X - Find the Attendant Console Pluggin
As of CUCM version 8.X, the server code related to the old Attendant Console Pluggin that was provided in versions 4.X and above no longer exists, and the Attendant Console Pluggin you've been using for years is not supported and / or simply won't work. You'll need to investigate the stand alone Cisco attendant console at and additional cost, or a third party solution.
With that, if you are performing upgrades from versions when the pluggin was supported through version 7, it theoretically is still supported. It is officially not supported on new installs of version 7 though. Of course, no one is installing new 7.X versions at this point, so what's the problem?
During a long, slow upgrade project to get a customer from 7 to 9, I found the pluggin is not available via the CUCM pluggins page after an interim upgrade to 7.0(2) .
With that, if you are performing upgrades from versions when the pluggin was supported through version 7, it theoretically is still supported. It is officially not supported on new installs of version 7 though. Of course, no one is installing new 7.X versions at this point, so what's the problem?
During a long, slow upgrade project to get a customer from 7 to 9, I found the pluggin is not available via the CUCM pluggins page after an interim upgrade to 7.0(2) .
Proceeding as cautiously through this project as I could, I wanted to have a copy in the event something else blew up. If all else fails, I like to keep in the operators' good graces.
As it turns out, although it didn't make it to the download web interface, you can still download the pluggin from the following URL:
https://YOUR_CUCM_SERVER_ADDRESS:8443/plugins/CiscoAttendantConsoleClient.exe
Happy upgrades!
Subscribe to:
Posts (Atom)
