Is Microsoft Really Going “Open”?

2017-07-27T00:00:58+00:00 April 14th, 2016|Azure|

Coretek Cloud Logo final

Many customers aren’t aware of the major shift Microsoft has been making over the last few years.  Microsoft SQL on Linux is a culmination of those changes.  With the announcement of Red Hat support and .Net on Linux, Microsoft has made a major move in the open source marketplace.

Did you know that almost all of the features in System Center 2013, OMS, Azure Backup, and Azure Site Recovery, treat Linux as an equal class citizen?  Windows — or Linux — is no longer a sticking point on the solutions we design and deploy.  With Windows or Linux we can deliver operational solutions on any platform.


Let us know if you have a unique requirement that has been challenging to your business, we are very confident we can help.


Jason M. Cornellier – Cloud Practice Director


Converting a VMware Linux Guest to Hyper-V…

2017-07-27T00:01:02+00:00 May 1st, 2014|Uncategorized|

If there were enough room, the full title for this article would actually be something more like, “Converting a Suse SLES or Opensuse Linux machine from either VMware Workstation or ESXi or to Hyper-V, even when you don’t have the VMware environment anymore…

To give you a little background, Microsoft recently released the MVMC v2 (, packed with some critical new features, including better handling of Linux VM guests.  And it just so happens that I have a small handful of dev/test Linux machines lying around from a VMware lab environment that I tore down a while ago that I’d love to have in my Hyper-V lab.  The problem is that I just don’t have the VMware workstation or space on my ESXi servers to bring the VMs back up and follow the standard documented procedure.

If you haven’t figured it out already, the basic problem here is that the Linux VMs (that came from the VMware environment) don’t have the Hyper-V drivers configured because they weren’t needed at installation (again, on VMware), but the Installation ISOs *do* have the drivers at the ready when booting the “rescue system”.

And while the very nice documentation provided with the converter kit (Microsoft_Virtual_Machine_Converter_Admin_Guide_2_0.docx) gets you close to knowing what you need to do, it doesn’t quite provide you with step-by step instructions, especially with the guests already downed or in an archive.


Without further ado, here’s how to convert and fix those Linux VMs.  Of course, there are a few particulars here; for instance, this procedure was tested with Opensuse versions 12.2 and 12.3, and SLES 11 sp3, but should be the same for other similar versions.  And it should go without saying that by following these instructions, you proceed at your own risk. 

Step 1: Install MVMC2

First, the installation.  Go to the MVMC2 download site, get the software, and install.  I recommend doing this on a Windows 8+ or Server 2012R2 machine, for a few small niceties (like defaulting to vhdx format, etc.).

Step2: Convert the Disk

Open Powershell *as Administrator* (right-click, run as Administrator), and load the module:

Import-Module "C:Program FilesMicrosoft Virtual Machine ConverterMvmcCmdlet.psd1"

We need to create a temporary folder for our converted disk — in my case on a separate drive from where my source VMs reside, to speed things up a tad:

md c:MvmcResults
cd c:MvmcResults

And then we can convert out source disk:

ConvertTo-MvmcVirtualHardDisk -SourceLiteralPath "E:Virtual MachinesOpensuse12.3Opensuse12.3.vmdk"

Next, move the newly converted disk to wherever you keep your virtual hard disks (I assume you have a designated location).

Then, create a Generation 1 Virtual Machine in Hyper-V (try to use the same name, memory settings, and so on as before), but choose to “Use an existing virtual hard disk” and set it to the newly converted hard disk.  But before you start it, attach the correct installation ISO (I use the tiny “network install” ISO).  Remember, it’s mandatory that you use the correct processor type ISO (32 vs. 64), and you should use the correct distro version.

Step 3: Boot and Mount the Alternate Root

Start the VM (booting from ISO), and choose “Rescue System” as the boot choice.  Tip: while the splash screen is up, hit the escape key and notice the Hyper-V drivers it chose; in my case it was only hv_netvsc and hv_storvsc, but you may have others.

Once at the “Rescue” prompt, enter “root” as the login.

Now, mount the proper disk partition for your root filesystem; this may take some guessing if you don’t remember which is which.  For instance, on some of my lab machines, I used /dev/sda2 as the full root filesystem.  On others, I created a separate partition for /boot, so the root file system was on /dev/sda3.  If you don’t know, you might have to mount a few of them and look and see what’s in them.  And of course, if you have a separate /boot, you’ll have to mount that too.  But for the examples that follow, we’ll assume the full root file system is all on /dev/sda2.

So mount the root filesystem under the alternate mount point, like this example:

# mount the root
mount /dev/sda2 /mnt
# you may have to mount /boot too, depending on your setup
# mount /dev/sda1 /mnt/boot
# you must re-mount the live dev and proc
mount -–rbind /dev /mnt/dev
mount -–rbind /proc /mnt/proc
# set the chroot environment
chroot /mnt

…and then we’re ready to actually do some fixing.

Step 4: Fix the Modules

(These next instructions are re-interpreted from the MVMC2 guide, courtesy Microsoft):

Use vi to edit /etc/sysconfig/kernel to include the Hyper-V modules.  Sorry, there’s not enough room here to teach you how to use vi…  😉  Add the “hv_” modules to the end INITRD_MODULES line, which *may* look something like this:

INITRD_MODULES="mptspi ata_piix ata_generic vmxnet3 vmw_pvscsi vmxnet”

…or perhaps like this (this example does not have VMtools drivers):

INITRD_MODULES="mptspi ata_piix ata_generic”

…and with your change, you’re making it look more like this (again, we’re only adding the hv_ modules to the end):

INITRD_MODULES="mptspi ata_piix ata_generic vmxnet3 vmw_pvscsi vmxnet hv_vmbus hv_netvsc hv_storvsc”

And finally, recreate the initrd with something similar to the following command (this example is taken from one of my older ones). The kernel and initrd specified in the command must match your current kernel the machine boots with.

mkinitrd -k /boot/vmlinux-3.7.10-1.11-desktop.gz -i /boot/initrd-3.7.10-1.11-desktop

…and you’re done!  Type “exit” to end the chroot environment, and “init 0” to shut down.  Go to the settings of the VM, and detach the ISO, and boot it up.

Phew!  You did it.  Enjoy your Linuxy goodness…


Finding Rogue KMS Servers in the Enterprise…

2017-07-27T00:01:08+00:00 February 8th, 2012|Uncategorized|

In larger Enterprises with Microsoft-based infrastructure, it’s highly likely that the licensing for the Windows 7 workstations will be based on the Microsoft KMS model.  If you don’t already know, this means you run servers in-house that register themselves into DNS as license providers, and Windows clients will learn of them (and become affiliated with them) to get a license, rather than contacting Microsoft themselves across the Internet.

Unfortunately, one problem that can occur is that someone who has access to the Microsoft license codes (like an I.T. worker, developer, etc.) might accidentally install a KMS license on a server that is not intended to be a KMS server.  And when a KMS license is installed, the server doesn’t know any better; and dutifully registers its KMS capability with the internal Active Directory based DNS as a VLMCS SRV record. 

Recently, I ran into a situation where I needed to hunt down and eliminate some accidentally rogue KMS servers that had cropped up across a large infrastructure, and be able to re-check at regular intervals.  While I originally wrote the script as a bash shell script for Linux, I re-wrote it into PowerShell recently for someone who asked, and I thought I’d post the new version here.

Mind you, this is a stripped-down version of the script, but it includes all that is needed to run the check manually for a hierarchical DNS infrastructure (although you may wish to strip out components if you just want to check the parent domain). 

Copy the contents below, paste them into a PowerShell script file (*.ps1), change the variables at the top… and have fun!


# Change the following 3 variables as needed.
# This script will loop through the subdomains, checking for KMS servers in each
# subdomain, and then at the parent domain.
$subs = @("subdomain1", "subdomain2", "etcetera")
$parentdomain = mydomain.local
$outfile = "checkKMS-Results.txt"
write "KMS check report..." | Out-File $outfile
write " " | Out-File $outfile -append
write "The only valid KMS servers are at the $parentdomain, as follows:" | Out-File $outfile -append
write "KMS1, KMS2, KMS3" | Out-File $outfile -append
write " " | Out-File $outfile -append
write "There should not be a KMS server at any of these locations:" | Out-File $outfile -append
foreach ($item in $subs)
  write "Checking subdomain: $item"
  $result = nslookup -type=srv _vlmcs._tcp.$item.$parentdomain. |findstr /C:"_vlmcs" /C:"svr hostname"
  if ("X$result" -eq "X")
    write "No registered KMS server in $item" | Out-File $outfile -append
    write "***KMS FOUND at this location: ***" | Out-File $outfile -append
    write $result | Out-File $outfile -append
write " "  | Out-File $outfile -append
write "On the contrary, the following should be valid KMS servers:" | Out-File $outfile -append
$result = nslookup -type=srv _vlmcs._tcp.$parentdomain. |findstr /C:"_vlmcs" /C:"svr hostname"
$result | Out-File $outfile -append
write "...Done!" | Out-File $outfile -append




VoIP For Business: Stability vs. Savings

2017-07-27T00:01:12+00:00 January 21st, 2010|Uncategorized|


How can VoIP save your business money?Digium Whitepaper

You want to or already have deployed a VoIP (Voice over Internet Protocol) capable phone system for your business, but where are the monthly cost savings, VoIP? You’ve seen some savings by reusing your existing company infrastructure, like network wiring, and you’ve seen a boost in productivity because of all the features that can come with VoIP, and specifically an IP PBX, but do you really need to entrust your voice to the wild west of the Internet to see any real impact on your monthly bill? We’ll explore ways to get the most out of an IP PBX (Internet Protocol Private Branch eXchange) deployment so that your calls are as cheap and as reliable as you are willing to make them. And we’ll look at ways to help you decide how much risk your company can tolerate in the name of slashing phone bills.

Wait, but isn’t VoIP free?

Not exactly, no. If you make a call using VoIP to another user of the same VoIP network, then yes, this call could potentially be free. This is really dependent on what the owner of that network has decided for their policy. If the owner of the network is you, as in the case of multiple IP PBX systems joined together, then yes, those calls are free.

So what are you paying for then?

If you’re not calling another VoIP user, like in the case where a VoIP call is made to a cell phone, somewhere, somehow, that call needs to jump out of the VoIP network and “terminate” into the PSTN (Public Switched Telephone Network). That’s the service you’re paying for when you’re paying for VoIP service (Fig 1).

The main reason that your phone calls are less expensive when using a VoIP provider is because they’re sending your call as far as they can with VoIP, and only sending it as short a distance as they can out on the PSTN. In other words, they’re saving by not sending the call long distance either.

An ITSP (Internet Telephony Service Provider) with many termination points all around the world can have rates well below a traditional carrier for this reason. Take, for example, a call you want to make from Los Angeles to someone’s regular home phone in Paris. If the VoIP carrier you’re using has a termination point in Paris, you’re in luck and the call will travel across the distance just like any other internet traffic (like if you sent an e-mail to someone in Paris), and then when it needs to go from that termination point in a data center out to the PSTN network in Paris, its just a local call, and therefore, cheap!


But all this goes out the window when you consider that most ITSPs are actually just reselling a larger, wholesale carrier’s minutes. So shopping for an ITSP can just come down to shopping for the lowest
rates. But buyer beware! Just like anything else, you tend to get what you pay for. There are definitely bargains to be had, but it’s important to know if the carrier you’re researching is reselling someone else’s minutes or if they actually have their own network. It may be better if they’re reselling a larger carrier’s minutes because that large company has a lot of infrastructure, presence worldwide, and support staff. On the other hand, you will get some frustrating answers from ITSPs that don’t own their own network if they’re experiencing an outage. Basically, there’s not much they can do about it. So if you are going to choose to go with a provider that resells rather than owns their own network, the best bet is to choose a carrier that resells several larger carriers’ minutes, instead of depending on just one.

Big Impact: Routing Calls Wisely

The whole goal here is to explore how routing your business calls through the right channels can impact your bottom line, without forcing you to jump into VoIP “head first” at the outset. VoIP may be cheap, but it’s typically no more reliable than the internet, so balancing with PSTN calls would be the wise deployment, due to the government regulations placed on our old telephone network.

Scenario One: Use VoIP to Just Call Between Offices

So easy, it should actually be difficult to NOT implement an IP PBX this way. From remote employees, to entire remote offices, by deploying IP handsets and IP PBXs at each location, all of your devices can just talk to each other without intervention by an outside agency. That is, they all speak the same language, no translation is necessary, so there’s nothing to pay for in that case but bandwidth. Presuming you’ve moved from a traditional PBX to an IP PBX, and have simply unplugged your old analog lines from the old system and plugged them in to the new system, you could still see some pretty decent savings by deploying this way. You could consider this to be the “safest” way to roll out an IP PBX, but unless your company does a lot of branch to branch calling or has a lot of employees working from home, you could probably aim a little higher.

Scenario Two: Add in VoIP for Select Outbound Calls

By adding in a VoIP provider to the mix, you can pick and choose through the Switchvox interface which calls should be handled by which route. Imagine your phone system, but instead of just having those old analog lines plugged in, you’ve also chosen to sign up for service with a VoIP service provider. In the Switchvox GUI interface, you can actually specify that for 911 calls, the system should send the call over the analog lines, but when you call New York, to use the VoIP service provider’s route. See what we did there? We used VoIP because it’s cheaper to call long distance using VoIP, but we used the analog lines when we didn’t care about cost and just wanted the most reliable call possible.

With Switchvox you can get as specific as you want with defining types of calls (any long distance call, any call to Los Angeles, any call to 858-234-9090) so that you can route them the way that makes sense for your business. And by using several VoIP providers, you can boost the cost savings even more. If you have multiple providers, you can set the Switchvox to use the provider that gives you the best rate for the call, e.g., use VoIPro to call China, but Vongo to call Dallas.

To balance a little reliability back in there, Switchvox can be set up with fail-over, or fallback routes for the calls that you specify. E.g., use Vongo to call Dallas, but if that fails, place the call using the good old PSTN lines. If you have multiple providers, you can get really fancy and stack the routes up as much as you like: use Vongo to call Dallas, but if that fails, use VoIPro, and if that fails too, use the PSTN. These fail-over routes can be put into place wherever it makes sense for your business. Would you like to fail over to the PSTN when your employees are trying to call China? It’s up to you! Do you want to spend$30 on a five minute phone call, or would you rather your employee give it another shot in 5 minutes when the outage has (hopefully) passed?

An even more granular level of control is to define the routes that should be used not just by the number your employee is dialing, but by whom the employee is. Maybe you don’t want your tech support team to call out using the analog lines unless its a 911 call and maybe they shouldn’t be allowed to dial 1-900 numbers at all. Maybe the CEO should be able to use the PSTN fail-over route when she’s trying to call China but the VoIP connection is unavailable. All of these options are open to you with Switchvox.

This deployment scenario is the most common way that Digium’s Switchvox IP PBX systems are deployed in the real world because they offer the most flexibility for balancing cost savings with reliability. If you find that your VoIP providers aren’t as reliable as your business demands, you can ratchet up the use of the PSTN lines for many of your calls. If you find your VoIP lines have never been a problem, you can start scaling up their use and really see the savings add up.

Scenario 3: VoIP Inbound

In the previous scenarios, we’ve been discussing outbound calls but it is possible to use VoIP for inbound calls as well. A phone number (or as many as you need) can be procured from many VoIP service providers. These are often called “DIDs.” It is often cheaper to get a DID than a PSTN phone line (that by nature comes with a phone number) and so it is an attractive option for many businesses trying to squeeze out the most cost savings possible with their new IP PBX. What many businesses fail to consider, however, is that they will often pay for outbound and inbound calls with this new number. With your old analog lines though, you probably didn’t pay for inbound calls. E.g., if John calls Jane using a regular phone line, he pays for the call based on how long he’s on the phone and Jane doesn’t pay a dime. With VoIP, unless you’re signed up for a plan that is a flat fee for both outbound and inbound, you’d pay both ways.

Another point to consider when evaluating moving your numbers to VoIP DIDs is number portability. Unless your VoIP service provider can transfer your numbers, there are generally some costs associated with changing your businesses phone numbers: printing new business cards, informing your clients, updating advertisements or websites, etc.

And the last reason that using VoIP for inbound calls is unusual in a business IP PBX is the reliability factor. If that call can’t reach the IP PBX, it’s a far worse thing for most businesses than if an outbound call fails. Think of it this way, if you’re sitting at your desk and try to call your customer in China and the call route rules don’t fail over to the PSTN so your call simply fails, you’re going to hang up the phone and try again in 5 minutes. If your customer, on the other hand, tries to call you and it doesn’t work, who’s to say they’re ever going to call back again? Ouch. And there’s nothing the IP PBX can do about this to fail-over, because the call isn’t getting to it. It can’t re-route a call that it doesn’t have.

The bottom line is to be cautious when assuming you need to switch all of your numbers to DIDs. A far more common way to deploy VoIP DIDs is to use them as back up numbers in case all of your analog phone lines are full. Making sure you’ve got enough PSTN lines to handle your inbound call volume is important, but if you find that one day your company has been covered in the New York Times and your phone is ringing off the hook, you can at least roll over to your DIDs. And if those happen to be down at that very instant, I’d say you were both having very good luck and very bad luck on the same day. In other words, this is probably a reasonable risk for most businesses.

So how does one implement this scenario? Your PSTN provider probably has an option available that you can add to your plan that will forward inbound calls to another number if all of your phone lines are busy. Just give them your VoIP DID and tell them that’s the number they should forward to. They don’t even have to know it’s a VoIP line, it looks just like a telephone number to them. If you are going to deploy this way, it is a good idea to look for a provider that will allow multiple inbound calls over the same DID, that way you’re pretty much guaranteed not to “ring busy” when your customers call on the busiest day.

Scenario 4: All VoIP, All the Time

Sometimes Switchvox IP PBXs are deployed as an office phone system that strictly use VoIP and they don’t have any analog lines plugged into them. One way that this happens is when a VoIP service provider actually doesn’t route your business’s calls over the Internet, but instead uses a private network. These types of providers can therefore offer data as well as VoIP service and can provide SLAs (Service Level Agreements) that other VoIP providers can not. They are actually in charge of what happens to your calls, rather than trusting them to the Internet. These types of providers can also offer QoS (Quality of Service) which prioritize your voice packets over your data packets, ensuring that your phone calls sound perfect. An often misunderstood aspect of VoIP is that it sounds bad- not true! It actually sounds better because its digital. What can sound bad is the network the call is on. Calls that travel over the Internet can often take on a robot-y sound or be choppy because they’re sharing that “information superhighway” with a lot of other traffic. QoS ensures a clear path from start to finish.

The other, more risky, but cheapest way to do an all VoIP system is to get a regular VoIP service provider account and a DID or two. You will want to make sure you have a plan for dialing 911 (some VoIP providers support this, others do not). This is, of course, both the cheapest (probably) way to deploy and fraught with the most risk (also probably). You may have great luck with this, and you may curse the day you ever tried it. For this reason, it’s recommended that you work up to this gradually, rather than jumping in feet first and having to scale back and make adjustments to cope with trouble.

Failures? Outages? What gives?

With all of this talk about failures and outages, you might be asking yourself just what you’re getting into! As I hope I’ve shown, VoIP can be deployed in such a way as to improve your call’s sound quality, be cheaper and just plain better, but there can be bumps in the road, which is why I’ve outlined these different deployment scenarios. These bumps can be caused by a lot of different things, like outages of your ISP, big Internet backbone style outages (fairly rare, but they happen), and outages at your VoIP service provider. The important thing to remember is that if your IP PBX cannot navigate the route from its location to your service provider, your calls will fail. The regular analog lines that we’ve come to depend on are essentially an old, proven dedicated network that’s regulated by our government to be up with “five nines” of reliability. The Internet is not such a beast, but it’s still pretty darn good.

Balancing Act: The Best of Both Worlds

This straightforward assessment of the situation hopefully gives you the tools to evaluate for yourself how you’d like to deploy VoIP in your network. You can deploy something very simple that almost emulates a traditional PBX to a system with least cost routing implemented with fail-over rules that keep your company’s communication running smoothly. There should be no reason to hesitate when it comes to deploying a next-generation phone system in your business!


To find out more about Digium, Switchvox, or the Open Source Asterisk Project, visit or call 1-877-4-CORETEK.

Digium Switchvox Releases New Version 4.5

2017-07-27T00:01:12+00:00 January 21st, 2010|Uncategorized|

Digium Switchvox system  – new 4.5 version features greater handset support

Switchvox 4.5 Release

Switchvox SMB 4.5 Extends the Power of the Web Interface to Phone Handsets

Digium’s Switchvox® SMB 4.5 is a powerful, full-featured and cost-effective VoIP Unified Communications (UC) solution designed for small- to mid-sized businesses. Switchvox SMB 4.5 delivers greater flexibility for your office communications, extending control of mission-critical applications traditionally accessed through the web interface directly to phone handsets.

Based on Digium’s Asterisk, the world’s most popular open source telephony engine, Switchvox SMB is a powerful IP PBX that integrates an easy-to-use web interface with innovative UC features such as fax, chat and video calling.

Call or email us today for an onsite demo!

Phone Feature Packs extend the power of Switchvox to Polycom phone handsets

The new Phone Feature Packs extend the power of the Switchvox to Polycom phone handsets for maximum control of the communications system.  Features that were previously only available through the web interface are now made available through Phone Feature Packs to these phone handset displays. Users can easily access powerful features from their phone handsets, such as call recording, visual voicemail, a searchable company directory and call parking lots. New options for more fundamental phone functions, such as hands free click-to-call dialing, distinctive ringtones for different types of calls, extension failover to a backup Switchvox SMB server, and support for multiple extensions on a single handset, are also available in version 4.5. 

Check out these other powerful Switchvox SMB 4.5 features!

·      User profiles— Caller profile information such as photo, extension, title and location.  This appears on the Switchboard and on the display of Polycom phones with Phone Feature Packs on internal calls.

·      Flexible language support— The Switchvox 4.5 GUI, manual, and inline help are available in English, UK English, Italian, Castilian Spanish, and Latin American Spanish. Sound packs, which include all the audio prompts used in the system, are available for these languages, as well as Australian English, French, and French Canadian. For businesses with international offices, users can customize their language settings to best complement their location and language preference.

·      Comprehensive monitoring—Digium has implemented the Simple Network Management Protocol (SNMP) for Switchvox 4.5, which gives administrators the ability to collect real time data about the status and health of their systems. For a comprehensive description of features, please contact us.

Leveraging Open Source to Solve the Windows 2000 End-of-Life Dilemma

2017-07-27T00:01:12+00:00 October 1st, 2009|Uncategorized|

Many companies are facing the challenge of how to transition from Windows 2000.  While the default reaction to this challenge is to move to a newer Windows release this approach can lead to other concerns:

  • Am I licensed for the new OS (especially when using the OEM supplied license)?
  • Do your applications and peripherals work with the newer Windows OS versions?

Despite these challenges, in most scenarios, with proper planning, the transition can be managed effectively.  However, in some cases IT departments should take the time to evaluate the progress that Open Source platforms have made in being a viable alternative.

If you are still using Windows 2000 it is likely that these systems are being used in a limited capacity.  When the systems needing to be replaced are ‘task oriented’ terminals and a thin client is a good alternative but the cost of replacing hardware may be prohibitive, there are a variety of Linux Distributions and Open Source applications that can prove to be a valuable alternative.  Take, for example, a scenario where a Windows 2000 system is used for a limited set of applications with specific hardware and peripheral requirements.  Even better, let’s assume the Windows 2000 system is being used as an RDP terminal.  A Linux desktop may be the perfect solution waiting to be discovered.

With the recent Linux distributions it’s easier than ever to develop a custom Linux image that can meet the challenge.  Take, for example, Puppy Linux 4.3.  This small yet powerful distribPuppyLogoution is packed full of hardware device support, tons of the most typical applications, a streamlined installation experience, and flexible deployment options.  All with a 110 MB footprint! 

Check out the goals of the Puppy Linux distribution here:

As with any IT project, don’t assume or accept marketing slicks in place of due diligence.  Do your homework, test and validate potential solutions, and plan for the full life cycle management of an approach.  If done properly your organization will be successful whether the answer is Windows  7, Puppy Linux, or something off the ‘beaten path’ altogether.  With the technology advancements of today’s operating systems, taking the time to re-evaluate the options may surprise you!

Source: Coretek Services –  Sr. Systems Architect