Skype For Business – Can not update OnPremLineURI as the user has dirsynced onpremise LineURI

September 24, 2017 – 5:24 pm

We had some legacy conference rooms that were renamed over the years, and as part of the infrastructure cleanup project we’re doing, I changed several attributes in the AD account to clean that up (anything that had to do with email/sip address was changed). Resync’ed with AD Connect and all worked well. Several hours later, we changed their licenses from an E3 license to a Skype Plan 2 license. From this point forward, I was unable to run “set-csuser -OnPremLineURI, as I was receiving an error message: “Can not update OnPremLineURI as the user has dirsynced onpremise LineURI.” Looking at the attributes, I could see that the OnPremLineURI and LineURI attributes were the same, and the OnPremLineURIManuallySet was “False” (as opposed to all our user accounts which have this set to “True”).

Say what? Didn’t have that problem a few hours before… So I checked everything I could and couldn’t figure out the issue, so I called Microsoft support. After a week of providing logs, answering irrelevant questions and getting nowhere, I finally got a call back from an “engineer” who told me basically there were 2 options.

  1. We stop syncing those accounts with AD Connect and they could manually update the LineURI for us <- Not acceptable.
  2. Delete the account and recreate. <- really???? For an attribute issue?

So I asked which was the on premises attribute that was converted into the LineURI and got not clear answer from them. So I tried this:

  1. Set the msRTCSIP-Line attribute (it was “not set”) to some dummy value and triggered an AD Connect sync.
  2. Checked in AD Connect to see if the attribute was properly synced and it was.
  3. Checked the online attributes with Get-CSOnlineUser for the OnPremLineURI value and it was the one I had set on premises.
  4. Cleared the attribute on premises and repeated steps 2 and 3.
  5. This time, both the OnPremLineURI and LineURI attributes were blank!
  6.  Tried running the the set-csuser -OnPremLineURI and it worked this time!

Moral of the story:

  1. Microsoft Support “Engineers” are clueless about troubleshooting anything. I have yet to understand the logic when they troubleshoot something. We’re 0/5 so far with cases we’ve opened with them, we always end up finding the solution ourselves. I had one case where while troubleshooting an Intune issue, the support engineer was taking screengrabs of the generic menus (not even our own settings – just the interface! As if he didn’t know what it was supposed to look like. Scary!)
  2. Most issues we’ve encountered so far have been attribute replication issues. Sometimes removing the licenses from the users and putting them back resolved the issues, or forcing a new value then reverting to the actual proper value (like in this case) fixes the issue.

I would have expected them to come up with this scenario as a first option, but they kept insisting that we had the attribute set on premises (which we didn’t) and that there was nothing to do.

Reconfigure Update Manager on VCSA

August 21, 2017 – 10:44 am

We had an issue with our vCenter appliance 6.5 when we upgraded to 6.5u1, that required a full redeployment. We backed up the database and redeployed the appliance. We took that opportunity to rename the appliance, which we were told was the only way to do that (backup/redeploy/restore) by VMware support.

After redeploying, everythin worked except for Update Manager. I narrowed it down to the service trying to use the old name still. So I went in to the MOB configuration and deleted the extension as we used to do in the Windows world. Well, there is no documentation out there to re-register the service on the appliance.

The only thing I had found was:

/usr/lib/vmware-updatemgr/bin/updatemgr-util register-vc

which fails…

So I opened a case with VMware support and 1 hour of drilling down and support came back with this:

Backup the configuration files in case…

cd /usr/lib/vmware-updatemgr/bin
cp extension.xml extension.xml_backup
cp vci-integrity.xml vci-integrity.xml_backup
cp jetty-vum-ssl.xml jetty-vum-ssl.xml_backup

Then re-register the extension with this command:

./vmware-vciInstallUtils -C /usr/lib/vmware-updatemgr/bin/ -L /var/log/vmware/vmware-updatemgr/ -I /usr/lib/vmware-updatemgr/bin/ -v -p 80 -U administrator@vsphere.local -P “password” -S /usr/lib/vmware-updatemgr/bin/extension.xml -O extupdate

chown updatemgr:updatemgr vci-integrity.xml

service-control –start vmware-updatemgr

Rolling back a vSphere upgrade

February 26, 2017 – 8:40 pm

Ahem… Being a vExpert doesn’t mean you don’t make stupid mistakes like everybody else…

I pushed an update to vSphere 6.5 on a host and tada! Purple screen… I rebooted, crossing my fingers that it was a one time thing but no, it came back. Then it dawned on me to check the HCL… The server is an HP DL585 G7 and it isn’t supported.

I opened a case with VMware to see if there’s was a way to recover without having to reconfigure everything (not the end of the world but…) And there is!

I was directed to this KB that points out that during boot there is a rollback feature! Never noticed/knew about that one. Been a while since I upgraded environments. Glad to see this!


vExpert 2017

February 15, 2017 – 8:36 pm

I was awarded a “vExpert” for 2017 by VMware! What an honour! Never thought I’d qualify for it, but I guess my humble efforts are recognized. Thank you VMware!

Introduction to VMware Photon OS

February 8, 2017 – 3:34 pm

I wanted to play with Photon, so I was looking for some ideas/purposes to deploy a Photon VM in a Windows “shop” 🙂

There’s always some docker packages you can find that can be useful (SMTP server for test/dev environments for example). One good use I found is to build our internal NTP server.

Here’s how I do it:

Create DNS record

an A record for the hostname, and a CNAME for an alias to refer to it in your various systems ( for example).

Set Static IP Address

mv /etc/systemd/network/ /etc/systemd/network/

then edit the file using VI








Set Hostname

hostnamectl set-hostname MYNTP.MYLAB.COM

hostname MYNTP



Disable IPTABLES (I know, not the most secure thing but that’s what I do)

Edit /etc/systemd/scripts/iptables

iptables -P INPUT ACCEPT




Update OS

tdnf update


set timezone

ln -sf /usr/share/zoneinfo/America/New_York /etc/localtime


Install nano

tdnf install nano


Enable NTP Server

tdnf install ntp

nano /etc/ntp.conf

— add the following configs:





tinker panic

restrict netmask nomodify notrap

restrict default kod nomodify notrap nopeer


restrict -6 ::1

driftfile /var/lib/ntp/drift/ntp.drift


Start service

systemctl start ntpd

systemctl enable ntpd

systemctl status ntpd


Troubleshooting commands

ntpq -p

date -R

ntpdate -q


Stretched cluster VM localisation

November 29, 2016 – 8:28 pm

A colleague asked me to help him out with an issue he had. On a stretched cluster, some VMs had storage on Site A but were powered-on on site B and that’s a no-no in a normal situation. There’s no built-in mechanism other than using DRS groups to do so. So I assembled bits and pieces I found online to create a script that would serve this purpose by creating 2 DRS groups and populating them based on which datastores the VMs were on.

Here’s the script:

# These groups must already exist
# VMs-On-SiteA
# VMs-On-SiteB
# Hosts-SiteA
# Hosts-SiteB
# And the following rules
# Bind-To-SiteA (should run)
# Bind-To-SiteB (should run)

# Initialize variables

$vCenter = “vCenterName.subnet192.lab”
$vCenterUser = “ServiceAccount@vsphere.local”
$vCenterPass = “MyPassword”
$ClusterName = “ClusterName”
$SiteA_Datastores = “SiteA*”
$SiteB_Datastores = “SiteB*”

$SiteA_DRSGroup = “VMs-On-SiteA”
$SiteB_DRSGroup = “VMs-On-SiteB”

# Update-DrsVMGroup

function Update-DrsVMGroup {
param (

$spec = New-Object VMware.Vim.ClusterConfigSpecEx
$groupVM = New-Object VMware.Vim.ClusterGroupSpec
#Operation edit will replace the contents of the GroupVMName with the new contents seleced below.
$groupVM.operation = “edit”

$groupVM.Info = New-Object VMware.Vim.ClusterVmGroup
$groupVM.Info.Name = $groupVMName

Get-VM $VMs | %{
$groupVM.Info.VM += $_.Extensiondata.MoRef
$spec.GroupSpec += $groupVM

#Apply the settings to the cluster

# vCenter Connection

Connect-VIServer $vCenter -User $vCenterUser -password $vCenterPass -WarningAction SilentlyContinue

# Housekeeping


# Populate the groups

$Cluster = Get-Cluster $ClusterName
$AllVMs = $Cluster| Get-VM

$SiteA_VMs = Get-Datastore $SiteA_Datastores | Get-VM
$SiteB_VMs = Get-Datastore $SiteB_Datastores | Get-VM

Update-DrsVMGroup -VMs $SiteA_VMs -groupVMName $SiteA_DRSGroup
Update-DrsVMGroup -VMs $SiteB_VMs -groupVMName $SiteB_DRSGroup

# Run DRS to move VMS to the proper places

Get-DrsRecommendation -Cluster $Cluster -Refresh
Apply-DrsRecommendation -DrsRecommendation -RunAsync

Another certification…

October 21, 2016 – 10:41 pm

I regularly post about the latest certification exams I took… And today was the first of two for Cisco’s CCNA Datacenter certification.

In my new role, I am doing a lot of Cisco UCS and a bit of Nexus configurations and since I had little to no exposure to these platforms, I wanted to get up to speed with the platforms. With 25+ years experience, i don’t think certifications mean that much anymore but it’s my way to challenge myself to learn new stuff, and have something to show for all the efforts as well. As long as my employers pay for the material/exams 🙂

On my list for the coming months/year are:
– 2nd CCNA Datacenter Exam
– Renew my VCAP (assuming it also renews the VCP) for vSphere
– If I get good hands-on projects, the VCIX-NV for NSX.

So it seems I have a busy year ahead 🙂

vSphere 6.5

October 20, 2016 – 10:12 am

Like many of you who didn’t make it to either VMworld conferences, I followed things online avidly. Some great things are coming for our beloved hypervisor! I won’t rehash what’s already been posted all over the place, but here’s a quick link to the information:

Introducing vSphere 6.5

What’s New in vSphere 6.5: vCenter Server


Upgrading ESXi Hosts to vSphere 6

October 17, 2016 – 7:15 pm

Once I loaded the UCS image in VUM, it’s a piece of cake to deploy and update the hosts.


I had one site with 2 hosts running on IBM x3650 servers, so I downloaded the Lenovo image for this platform and loaded it up in VUM. Start the deployment, and the server ends up stuck in a loop.

A quick look with the remote IMM and I found out that host had vmnic0 disconnected (but vmnic1 was connected so management was accessible). It appears that in order for the upgrade to work properly, vmnic0 MUST be plugged in!

So I had to mount the ISO using the IMM and perform a manual update on that one (since nobody was at the remote site to reconnect that interface). There’s a KB for this issue actually:

Nice to know!

VMware VCSA Migration

October 17, 2016 – 7:10 pm

Last weekend I completed an upgrade/migration from vCenter 5.5 on Windows to vCenter Appliance 6.0 using the tool provided by VMware.

Everything went fairly smoothly – the migration tool was flawless. I made sure to take care of all the dependencies (vShield, vCOps, 3rd party plugins) first, upgrading them to a vSphere 6 compatible version. For some plugins, I simply uninstalled them, to reinstall later (VUM for example) as there was no particular customization that required saving the database/config.

I did have one issue with AD Integration. After the migration, I wasn’t able to authenticate with my AD credentials. I ended up having to remove everything (In VCSA, leave the domain and remove all AD configurations (groups, accounts, permissions, etc..) and in AD, delete the computer object.

Afterwards, doing everything step by step I was able to bring it back to a functional level. I had read that simply rejoining the appliance would do the trick but not so.