Recently, I had the need to analyze phone call data to answer questions such as how many phone calls were received in a given day and how frequently voicemail answered instead of a live person. In this scenario, I was fortunate enough to have a fairly accessible phone system to work with — a Cisco UC520. While this guide is specific to working with a Cisco UC520 device, most Cisco phone systems (the UC series or anything utilizing CUE/CME) should be pretty comparable.
So, you want to be able to analyze Cisco call data? Well, you’re in luck! There are three major steps to this process:
- Extract raw call data from the phone system
- Capture the exported data and interpret it
- Insert it into SQL Server and perform reporting
This won’t be a complete step-by-step guide, but I’ll try to hit all the high points and am always open to questions.
Having just recently successfully installed the current release of SSDT-BI (the current version as of this writing is based on SQL Server 2014 32-bit and the Visual Studio 2013 Integrated Shell), it was time to finally open up some SSRS (SQL Server Reporting Services) projects and get to work.
For anyone that use used the report Preview button within SSDT-BI, you know getting it to work can be a bit dicey. Microsoft has changed the internal behavior of what happens behind the scenes when the preview button is pressed, and that has created a number of problems.
No surprise, the first time I pressed the preview button, I was greeted with this:
Report Preview error in SSDT-BI
Well, that’s not good. I should preface this by saying that I did two significant things to ultimately resolve this issue. It’s possible that only the second one was needed, but I’m going to list them both (as well as a workaround) just in case it’s helpful.
With all of my driver, aesthetic, and networking issues worked out in previous parts, it was time to get down to business. After all, I’m going to have to do some work from this laptop at some point, right? And in the Microsoft Business Intelligence world, that means I’m going to need SSDT-BI (SQL Server Data Tools – Business Intelligence). As of this writing, the current version of SSDT-BI is still based on SQL Server 2014 32-bit with the Visual Studio 2013 Integrated shell. It’s expected at some point, with the release of 2016, there’ll be a new and improved version more tightly integrated into Visual Studio 2015, but for now, if you want to edit SSRS projects, this is the way to go.
I started out by downloading the currently release of SSDT-BI, which is 32-bit only (regardless if you’re using a 64-bit machine).
I encountered my first minor hurdle during the initial install. Since SSDT-BI is based on SQL Server 2014 32-bit, it doesn’t play nice with SQL Server 2014 64-bit. I wasn’t thinking clearly and when presented with the option to “Perform a new installation” or “Add features to an existing instance,” I first tried to add features and the installer yelled at me for having an incompatible installation already in place (SQL Server 2014 64-bit). So the correct answer is Perform a new installation, which will put these 32-bit components side-by-side with any existing 64-bit components.
After selecting the right installation type and checking the box for the SQL Server Data Tools – Business Intelligence for Visual Studio 2013 shared feature to install, I thought I was on easy street. Boy was I wrong, the fun was just beginning. While the installer was running, it eventually failed with this error:
SSDT-BI Install Error – VS Shell Installation has failed with exit code -2147205120
That’s not good. I immediately tried all the basic IT things before going deeper. I rebooted and retried the installation, this time running as administrator. Same error. Time to go deeper.
Following the error dialog is more detail regarding the error. To any developer that writes an installer that includes the option to view detailed log files….THANK YOU.
SQL Server Data Tools – Business Intelligence for Visual Studio 2013 installation completed with failures
My Windows 10 journey continues. In Part 1, I worked through a few very minor hardware/driver issues. In Part 2, I addressed some styling issues with window titles. To this point, my issues have been largely cosmetic (well, maybe getting sound to play through my speakers was important!) but this next issue encountered was a bit more serious.
Since at least Windows XP, Windows has had a built in VPN client. This is useful for connecting to non-hardware specific VPN servers, such as Microsoft Routing and Remote Access. Continuing with the trend, Windows 10 also has a built in VPN client. As with previous versions of Windows, it can be configured in the same was as always. Go into the Network and Sharing Center, choose Set up a new connection or network, then choose Connect to a workplace and enter the relevant VPN information.
Setting up a Windows 10 VPN Client
As anyone who has configured this type of VPN knows, there is typically one more non-intuitive step remaining. With the default configuration of the Windows VPN Client, all traffic is sent across the VPN, even traffic that doesn’t need to. For instance, if you need to contact the file server on the other side of the VPN, this needs to go across it. If you need to contact google.com, this doesn’t really need to go across it. Sending unnecessary traffic across the VPN typically has a pretty significant performance impact on your non-VPN traffic. Fortunately, a feature called “split tunneling” allows for this functionality to be disabled so only VPN traffic goes across the VPN and non-VPN traffic doesn’t. Seems pretty intuitive!
UPDATE: As of the November 2015, “Threshhold 2” update, the below theme no longer works (Microsoft has intentionally disabled it while they make changes to the theme system). They did, however, through the normal themes settings, allow for the title bar color to be changed natively via the Personalization -> Colors menu)
I recently decided to upgrade my laptop to Windows 10 with a clean installation. Things went great, with only a few very minor hardware/driver issues which I covered in Part 1. With everything running great, it was time to start customizing the default look a bit.
I’m using a traditional non-touchscreen laptop. During the day, it’s docked in a dual monitor configuration with two large displays and in the evenings only the built in 14″ screen is used. The first thing that really jumped out at me with the new theming of Windows 10 is the jarring look of the title bars. Here is one of the more jarring examples:
The default white Windows 10 title bar shown in Command Prompt
The white and the black really collide. This is one of the more extreme examples, but even in other applications, such as Chrome, it just looks weird having that much of a bright color on the top of every window.
The default white Windows 10 title bar shown with Chrome
With Windows 10 having officially released earlier this week, I decided it was time to get on the bandwagon and upgrade my Windows 7 Enterprise laptop to Windows 10 Enterprise. A large part of my motivation for performing this upgrade was to get rid of all the junk that has built up over the years (anybody who has used SQL Server Management Studio or Visual Studio knows just how many different component versions can pile up over time), so I had no intention of even trying an upgrade. Clean install all the way!
For reference, I’m using an older laptop, an HP EliteBook 8460p. The installation went off without a hitch and on bootup, the system was fully functional. Looking in Device Manager, there were only 4 unrecognized devices (which is great since no drivers from HP’s website had yet been installed). For each unknown device, it’s possible to right click on it, select Properties and then the Details tab, then find the Hardware Ids item. If you then search for one of the items in the value field, it’s almost guaranteed that someone on the Internet has already search for and identified what that component was.
In my case, I was missing drivers for four pretty non-critical devices:
- “Trusted Platform Module” – The Windows 8.1 version of the Intel Chipset drivers available on HP’s support site for the laptop took care of this one.
- “JMicron Card Reader – The Windows 8.1 version of the Card Reader available on HP’s support site for the laptop took care of this one.
- “HP 3D DriveGuard” – Skipped, unneeded
- “Validity Sendor Driver” – Skipped, unneeded
Everything seemed to be running great from a hardware standpoint until I noticed that my sound seemed really quiet. My typical setup at the office is for the HP EliteBook 8460p to be docked in a standard HP docking station with external speakers plugged into the docking station’s audio out jack. It turns out only the laptop’s internal speakers were functioning. I verified that the sound device was properly detected and showing correctly in Device Manager as an IDT audio device and everything looked good in the Sounds control panel applet. I performed a full Windows Update and let it grab any drivers it wanted to update and the issue continued.
After a bit of research, I determined that even though the sound drivers install natively with the Windows installation, the full sound driver/software package from HP is needed for the dock’s audio jack to function. There isn’t a Windows 10 version of this, but fortunately the Windows 8.1 version seems to work just fine. It hasn’t been updated since November of 2013, but I guess if it ain’t broke, don’t fix it.
After resolving those minor issues, installed my Samsung SSD software, all remaining Windows Updates, and then it was time to begin the journey of reinstalling a lot of software. Altogether, I’m very happy with how well Windows 10 performs on hardware that is definitely far from new.