Fixing Failed Exchange 2010 Database Content Indexes

I recently assisted a client over the weekend to patch their Exchange 2010 infrastructure with the latest service pack and rollup packs, and one of the issues I came across after the patching was that some of the database content indexes would be listed as Failed. This problem is one that I encounter quite frequently but never remember the exact cmdlet to correct the problem so this blog post serves to be something I can reference to in the future.

The following cmdlet can be used to list all of the databases and the health of the Content Index State:

Get-MailboxDatabaseCopyStatus -server <mailboxServerName>

The following cmdlet can be used to list only the databases with failed database content indexes:

Get-MailboxDatabaseCopyStatus –server <mailboxServerName | where {$_.contentindexstate -like "Failed"}

The following cmdlet will retrieve all of the databases with the content index listed as failed then use the Update-MailboxDatabaseCopy cmdlet to fix the indexes:

Get-MailboxDatabaseCopyStatus –server <mailboxServerName>| where {$_.contentindexstate -like "Failed"}

| Update-MailboxDatabaseCopy -catalogonly

The following is a sample output of the series of cmdlets used:

[PS] C:\Windows\system32>Get-MailboxDatabaseCopyStatus -server exmb01

Name Status CopyQueue ReplayQueue LastInspectedLogTime ContentIndex

Length Length State

---- ------ --------- ----------- -------------------- ------------

DB06\EXMB01 Healthy 0 0 3/28/2015 6:17:07 PM Healthy

DB05\EXMB01 Healthy 0 0 3/28/2015 6:15:10 PM Healthy

DB04\EXMB01 Healthy 0 0 3/28/2015 6:10:34 PM Healthy

DB03\EXMB01 Healthy 0 0 3/28/2015 6:17:26 PM Failed

DB02\EXMB01 Healthy 0 0 3/28/2015 6:15:19 PM Healthy

DB01\EXMB01 Healthy 0 1 3/28/2015 6:17:40 PM Healthy

[PS] C:\Windows\system32>Get-MailboxDatabaseCopyStatus -server EXmb01 | where {$_.contentindexstate -like "Failed"}

Name Status CopyQueue ReplayQueue LastInspectedLogTime ContentIndex

Length Length State

---- ------ --------- ----------- -------------------- ------------

DB03\EXMB01 Healthy 0 0 3/28/2015 6:17:26 PM Failed

[PS] C:\Windows\system32>Get-MailboxDatabaseCopyStatus -server EXmb01 | where {$_.contentindexstate -like "Failed"}

| Update-MailboxDatabaseCopy -catalogonly

[PS] C:\Windows\system32>Get-MailboxDatabaseCopyStatus -server EXmb01 | where {$_.contentindexstate -like "Failed"}

[PS] C:\Windows\system32>

Using PowerCLI to create new role and assign service account used by VMware App Volumes service account permissions for vCenter Server 5.5

One of the most exciting products I've been working with recently has been VMware App Volumes as most of the clients I work with that currently use VMware Horizon View have a need for customizing their virtual desktops but do not want to additional overhead of managing multiple master images. The deployment is actually quite simple (I'll write another blog post demonstrating this) and one task in particular that I've been performing frequently which could be automated is the creation of the service account that the App Volumes Manager uses to access vCenter. Those who may have come across my previous blog posts would know that I'm a huge fan of automating mundane and repetitive tasks so this post serves to do so for configuring the service account used by App Volumes Manager.

The permissions required for the service account that App Volumes Manager uses to connect to vSphere vCenter is displayed in one of the steps during the initial configuration:

Required vCenter Permissions

• Datastore
• Allocate space
• Browse datastore
• Low level file operations
• Remove file
• Update virtual machine files
• Folder
• Create folder
• Delete folder
• Global
• Cancel task
• Host
• Local operations
• Create virtual machine
• Delete virtual machine
• Reconfigure virtual machine
• Resource
• Assign virtual machine to resource pool
• Sessions
• View and stop sessions
• Tasks
• Create task
• Virtual machine
• Configuration
• Add existing disk
• Add new disk
• Add or remove device
• Change resource
• Remove disk
• Settings
• Interaction
• Power Off
• Power On
• Suspend
• Inventory
• Create from exising
• Create new
• Move
• Register
• Remove
• Unregister
• Provisioning
• Clone template
• Clone virtual machine
• Create template from virtual machine
• Customize
• Deploy template
• Mark as template
• Mark as virtual machine
• Modify customization specification
• Promote disks
• Read customization specifications

Manually configuring the permissions from within the vCenter client would look as such:

Datastore

Folder

Global

Host > Local Operations

Resource

Sessions

Tasks

Virtual Machine > Configuration

Virtual Machine > Interaction

Virtual Machine > Inventory

Virtual Machine > Provisioning

The cmdlet to execute to automatically create a role named App Volume Manager Service and assign the permissions as displayed in the screenshots above are as follows:

$priv = Get-VIPrivilege -ID Datastore.AllocateSpace,Datastore.Browse,Datastore.FileManagement,Datastore.DeleteFile,Datastore.UpdateVirtualMachineFiles,Folder.Create,Folder.Delete,Global.CancelTask,Host.Local.CreateVM,Host.Local.DeleteVM,Host.Local.ReconfigVM,Resource.AssignVMToPool,Sessions.TerminateSession,Task.Create,VirtualMachine.Config.AddExistingDisk,VirtualMachine.Config.AddNewDisk,VirtualMachine.Config.AddRemoveDevice,VirtualMachine.Config.Resource,VirtualMachine.Config.RemoveDisk,VirtualMachine.Config.Settings,VirtualMachine.Interact.PowerOff,VirtualMachine.Interact.PowerOn,VirtualMachine.Interact.Suspend,VirtualMachine.Inventory.CreateFromExisting,VirtualMachine.Inventory.Create,VirtualMachine.Inventory.Move,VirtualMachine.Inventory.Register,VirtualMachine.Inventory.Delete,VirtualMachine.Inventory.Unregister,VirtualMachine.Provisioning.CloneTemplate,VirtualMachine.Provisioning.Clone,VirtualMachine.Provisioning.CreateTemplateFromVM,VirtualMachine.Provisioning.Customize,VirtualMachine.Provisioning.DeployTemplate,VirtualMachine.Provisioning.MarkAsTemplate,VirtualMachine.Provisioning.MarkAsVM,VirtualMachine.Provisioning.ModifyCustSpecs,VirtualMachine.Provisioning.PromoteDisks,VirtualMachine.Provisioning.ReadCustSpecs

New-VIRole -Name "App Volume Manager Service" -Privilege $priv

With the role created, you can execute the following cmdlet to assign the domain service account to the vCenter object (top most level):

$rootFolder = Get-Folder -NoRecursion

$myPermission = New-VIPermission -Entity $rootFolder -Principal “domain\service-avm” -Role “App Volume Manager Service” -Propagate:$true

Note that the cmdlets above were tested with VMware vCenter 5.5 Update 2d and VMware App Volumes Manager 2.6.0.1226.

Windows Mobile 6 Classic handheld device is not detected in a VMware Horizon View 6 virtual desktop as a USB device

I was recently asked by a client to look at an issue with a device that her land survey team used which was not being detected as a USB device in a VMware Horizon View 6 virtual desktop.  The device is made by a manufacturer named Nomad and its operating system details are as follows:

Windows Mobile 6 Classic

CE OS 5.2.1946 (Build 18550.0.7.4)

2007 Microsoft Corporation

The device the user is using to access the virtual desktop is an HP t520 thin client with the Smart Zero operating system as shown in the following screenshot:

The handheld device was previously working when the user used a full Dell PC to access the view desktop so the first item I checked was whether the device was detected from within the thin client’s operating system and I could see that the device was present and mounted.  I then went to check the Device Manager list of the VDI’s Windows operating system to see if the device was present but it wasn’t.

As I was beginning to run out of ideas, I went ahead and tried searching on the internet to see if there were any known issues with this device and was able to find the following Microsoft KB:

You cannot synchronize a Windows Mobile-based device by using ActiveSync 4.x
https://support.microsoft.com/en-us/kb/938323

Although the KB wasn’t specific to VDIs, I went ahead and tried disabling the Enable advanced network functionality on the device:

I noticed that the virtual desktop immediately detected the device, started installing the driver and eventually displayed the device in Device Manager as a Portable Device with the name Tripod Data Systems Nomad:

Windows Mobile Device Center was what the user used to access his files so I went ahead and launched the application:

… and the application immediately displayed the status as Connected:

I was also able to browse the device’s drive through Windows Explorer:

Hope this helps anyone out there who may experience the same issue.

Migrated user from Exchange 2010 to 2013 is unable to modify shared calendars that the user has permissions on

I was recently asked by a client to assist with troubleshooting a calendar issue for a user who had been recently migrated from their Exchange 2010 server to Exchange 2013.  Both 2010 and 2013 servers still exist in the environment during the coexistence but one specific user appear to no longer have permissions to edit shared calendars that they had previously been able to.  The user would try send multiple requests for permissions to the calendar owner, the owner would approve but the user would be unable to get edit permissions to the calendar.

The first checks I immediate performed was to use the Get-MailboxFolderPermission cmdlet:

Get-MailboxFolderPermission "<userName>"

… to list the permissions of the shared calendar and I was able to immediately identify that the user having access issues either had view permissions or didn’t have permissions at all.  I proceeded to use either:

Set-MailboxFolderPermission "<userName>:\calendar" -user "<userName>" -accessrights "Editor"

or:

Add-MailboxFolderPermission "<userName>:\calendar" -user "<userName>" -accessrights "Editor"

… to grant the user permissions to other users calendars.  After setting the permissions correctly, I went ahead to test the user’s access from a workstation with Outlook 2010 and was able to access the calendars as well as create/edit items.  However, testing access from Outlook 2013 exhibited the same issue as originally reported by the user.

After performing troubleshooting steps such as recreating the Windows user profile, Outlook profile, configuring the user to cache the mailbox then disable caching without results, I went ahead and decided to reinstall Office 2013 with SP1 integrated.  The reinstall did not fix the issue so I wrote down the version numbers:

Microsoft Outlook 2013 15.0.4569.1503

MSO 15.0.4605.1000 32-bit

Then ran Windows Updates to see if there were patches available:

Continued to install the updates and was able to get the calendar sharing permissions to work properly.  What’s strange was that the updated Outlook version that now works still as the same version 15.0.4569.1503

Not exactly what I would have expected to fix the problem but seeing how this whole ordeal took a good 3 hours of my time, I hope this blog post would be able to save someone else’s time.

Controlling Citrix XenApp 7.6 Citrix Receiver published applications on a desktop’s start menu

I was recently asked by a client whether it was possible to control Citrix XenApp 7.6 Citrix Receiver published applications on a desktop’s start menu.  By this he meant that many users did not like the fact that applications were put into the start menu because they tend to get confused as to what applications were local and what was a remote Citrix application.  The client felt that simply using the Citrix Receiver application list window was sufficient so what they wanted was to either stop placing Citrix published applications in the start menu or put it into a folder named something like Citrix Apps.

What I found was some users on forums mentioned that it was possible to do this by modifying the config.aspx file located in the folder C:\inetpub\wwwroot\Citrix\GCUKCitrix\Views\PnaConfig on the StoreFront server.

http://discussions.citrix.com/topic/345791-storefront-20-receiver-410-change-start-menu-folder-shortcut/

The section all users reference to is the following section:

<PNAgent_Configuration xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance" >
    <FolderDisplay>
        <StartMenuDisplay>
            <Enabled modifiable="true" forcedefault="false">true</Enabled>
            <RootFolder root="programs" modifiable="true" forcedefault="false"></RootFolder>
        </StartMenuDisplay>
        <DesktopDisplay>
            <Enabled modifiable="true" forcedefault="false">false</Enabled>
            <Icon>
                <Name modifiable="true" forcedefault="false"></Name>
            </Icon>
        </DesktopDisplay>
        <SystemTrayMenuDisplay>
            <Enabled modifiable="true" forcedefault="false">true</Enabled>
        </SystemTrayMenuDisplay>
    </FolderDisplay>
    <DesktopIntegration>
        <StartMenu>add</StartMenu>
        <Desktop>add</Desktop>
    </DesktopIntegration>
    <ConfigurationFile>

Unfortunately, I tried every combination and wasn’t able to control the published applications from the StoreFront server:

Note that the Citrix StoreFront version I tested with is 2.6.0.5031:

What did ended up working was editing the StartMenuDir REG_SZ registry key at the following location on the client computer where the Citrix Receiver is installed:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Dazzle

Note how my laptop now puts all of the Citrix published applications into a folder:

The registry key solution works well with desktops joined to the domain but doesn’t for remote clients that are not a part of the network which is a common scenario for clients I work with (i.e. Hospital publishing applications for doctor offices).  Not willing to settle with seeing the suggestions on forums but unable to replicate them in the environment, I opened up a support case with Citrix and got an engineer to confirm that you cannot control the way applications are published on the remote client because the published applications are controlled by the Citrix Receiver and not the StoreFront.

I really hope this changes in the future.

Attempting to launch VMware SRM plug-in throws the error: “The server ‘192.168.155.10’ could not interpret the client’s request. (The remote server returned an error: (404) Not Found.)”

Problem

You’ve recently upgraded vCenter from 5.1 to 5.5 and quickly noticed that you receive the following error when attempting to load Site Recovery Manager:

Connection Error: Lost connection to SRM Server 192.168.155.10:8095

The server ‘192.168.155.10’ could not interpret the client’s request. (The remote server returned an error: (404) Not Found.)

Lost connection to remote SRM server at 192.168.155.10:8095.(The server ‘192.168.155.10’ could not interpret the client’s request. (The remote server returned an error: (404) Not Found.))

Solution

The reason why this error is thrown is because there is a mismatched in version between vCenter and Site Recovery Manager. Note that the screenshot below shows that the version for vCenter is 5.5.0.43769 while SRM is 5.1.1.7655:

To correct this issue, use the VMware Product Interoperability Matrixes to determine what version of SRM supports the installed vCenter then proceed to upgrade the VRA (if it is used) and then SRM:

Generating SSL certificate with OpenSSL for Cisco Wireless Controller

I recently had to use OpenSSL to generate a CSR and complete the certificate request for a Cisco Wireless Controller and noticed that the Cisco provided guide did not include some steps that caused errors to be thrown so I thought it would be good to document the process here in this blog post in case I ever had to do it again.

Cisco recommends OpenSSL 0.9.8 but I was unable to find it because it is most likely very old so I downloaded version 1.0.0q here:

https://slproweb.com/products/Win32OpenSSL.html

The first error you will run into is the following when you try to execute openssl.exe:

C:\OpenSSL-Win32\bin>openssl.exe

WARNING: can't open config file: C:\OpenSSL-Win32\bin\openssl.cfg

OpenSSL>

The reason why this error is thrown is because a path needs to get set up for the openssl.cfg configuration file.  Where it is set up does not matter as it just needs to be a valid and accessible path so the following will place it in the C:\OpenSSL-Win32\bin folder:

C:\OpenSSL-Win32\bin>set openssl_conf=c:\OpenSSL-Win32\bin\openssl.cfg

Openssl.exe will execute without errors once the path is set:

C:\OpenSSL-Win32\bin>openssl

OpenSSL> req -new -newkey rsa:2048 -nodes -keyout mykey.pem -out myreq.pem

Loading 'screen' into random state - done

Generating a 2048 bit RSA private key

.................+++

........................................................................+++

writing new private key to 'mykey.pem'

-----

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [AU]:

State or Province Name (full name) [Some-State]:

Locality Name (eg, city) []:

Organization Name (eg, company) [Internet Widgits Pty Ltd]:

Organizational Unit Name (eg, section) []:

Common Name (e.g. server FQDN or YOUR name) []:

Email Address []:

Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []:

An optional company name []:

OpenSSL>

Once the process shown above is complete, a myreq.pem file will be generated with content similar to the following:

-----BEGIN CERTIFICATE REQUEST-----

MIIC+TCCAeECAQAwgZoxCzAJBgNVBAYTAkJNMREwDwYDVQQIDAhIYW1pbHRvbjER

MA8GA1UEBwwIS5hklohjggf5TAPBgNVBAoMCEFyaWVsIFJlMQswCQYDVQQLDAJJ

VDEYMBYGA1UEAwwPd2xjLmFyaWVscmUuY29tMSswKQYJKoZIhvcNAQkBFhxhbmRy

ZXcud29vZHdvcnRoQGFyaWVscmUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A

MIIBCgKCAQEA1R43325hjkuiukjl;o9oiiH2x3xoAyZidlW1r3TrdTzcCEqetyYO+e34C

TFAIKx6wWocvIX9GBuNQ7RJmLlM40DaHJXhPbPQvBtyvzJunR+ABvtcnZtfQ63tV

279+rHTrHaspVJU4zEHg9vV6cq6Hhx4mVQfwn+9hjI/a+J4mnTs75giRlgLQna10

XG2XMvmLEvqV5FKQIFuJlYAz5N/A/Qnh3+3lRPBuR5kYSinMeT5WVKORYySdSk4r

SAoGb1gwp1zDirskfhwMzSDNCJAq7gSsc9BA3oITuCoiyB7zonsfEI6XCZ4DZsL5

JJa1a7M1FhcJiU3ULZ8HDLs7Wx+bi7oJwQIDAQABoBkwFwYJKoZIhvcNAQkHMQoM

CFBAc3N3MHJkMA0GCSqGSIb3DQEBBQUAA4IBAQBEjhRQtyMp3qLXkL/h46RVgHOH

P5rPoNXuKhgnTuFrIttyG6ON9hs/w/Ax2tc1rkhCJ3920O9FA9cI5L/GwQzmJXl1

WutujW3t/ysUX3th5ewkiIeYaKeP8lZuAfkhfrmik1SrBz2O8WGwPSOauSH1UgcXo

ubqDWt8MMOnq/GCZ6l/qDYumw47uV9ZeRBBPeMEc7VqN/LJUUdyzJ95thzX9mFwg

Xe47BewbmjKWgwRPotZu702oqU3MNIc0t+IbWdRRhfhLz+PvOBqRxvocdyZE2Szy

8eZfR/0wFr33tzXnqD4DMv2smWGyLpgcymUlz1GXrjF75xuO+Nm7ehqTMFL8

-----END CERTIFICATE REQUEST-----

Copy the content above and submit it to your preferred Certificate Authority to obtain an Apache compatible response CRT file a long with the certificate chain.  With the files obtained from the CA, proceed and open up the files in a text editor and paste them in the following order:

-----BEGIN CERTIFICATE-----

*Device cert*

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

*Intermediate CA cert*

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

*Root CA cert*

-----END CERTIFICATE-----

Below is an example of what it should look like:

Below is the file in its proper format:

-----BEGIN CERTIFICATE-----

MIIFTTCCBDWgAwIBAgIJAKABGuxLwr3OMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYD

VQQGEwJVUzEQMA4GA1UECBMHQXJpem9uYTETMBEGA1UEBxMKU2NvdHRzZGFsZTEa

MBgGA1UEChMRR29EYWRkeS5jb20sIEluYy4xMzAxBgNVBAsTKmh0dHA6Ly9jZXJ0

aWZpY2F0ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeTEwMC4GA1UEAxMnR28gRGFk

ZHkgU2VjdXJlIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MREwDwYDVQQFEwgwNzk2

OTI4NzAeFw0xNTAzMTUwMjI5MzhaFw0xNjAzMTEyMDE0MzhaMD0xITAfBgNVBAsT

GERvbWFpbiBDb250cm9sIFZhbGlkYXRlZDEYMBYGA1UEAxMPd2xjLmFyaWVscmUu

Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1R38Ur3NWr3WhhHG

PH2x3xoAyZidlW1r3TrdTzcCEqetyYO+e34CTFAIKx6wWocvIX9GBuNQ7RJmLlM4

0DaHJXhPbPQvBtyvzJunR+ABvtcnZtfQ63tV279+rHTrHaspVJU4zEHg9vV6cq6H

hx4mVQfwn+9hjI/a+J4mnTs75giRlgLQna10XG2XMvmLEvqV5FKQIFuJlYAz5N/A

/Qnh3+3lRPBuR5kYSinMeT5WVKORYySdSk4rSAoGb1gwp1zDirskfhwMzSDNCJAq

7gSsc9BA3oITuCoiyB7zonsfEI6XCZ4DZsL5JJa1a7M1FhcJiU3ULZ8HDLs7Wx+b

i7oJwQIDAQABo4IBwDCCAbwwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEF

BQcDAQYIKwYBBQUHAwIwDgYDVR0PAQH/BAQDAgWgMDQGA1UdHwQtMCswKaAnoCWG

I2h0dHA6Ly9jcmwuZ29kYWRkeS5jb20vZ2RzMS0xMTIuY3JsMFMGA1UdIARMMEow

SAYLYIZIAYb9bQEHFwEwOTA3BggrBgEFBQcCARYraHR0cDovL2NlcnRpZmljYXRl

cy5nb2RhZGR5LmNvbS9yZXBvc2l0b3J5LzCBgAYIKwYBBQUHAQEEdDByMCQGCCsG

AQUFBzABhhhodHRwOi8vb2NzcC5nb2RhZGR5LmNvbS8wSgYIKwYBBQUHMAKGPmh0

dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeS9nZF9pbnRl

cm1lZGlhdGUuY3J0MB8GA1UdIwQYMBaAFP2sYTKTbEXW4u6FX5q653aZaMznMC8G

A1UdEQQoMCaCD3dsYy5hcmllbHJlLmNvbYITd3d3LndsYy5hcmllbHJlLmNvbTAd

BgNVHQ4EFgQUmhLDlWChQjzT5mbB7PoGmPdiW+owDQYJKoZIhvcNAQEFBQADggEB

AEtuQGHJBZv8YAFtdIX3YRh+4+pVjpvfZ6TDyRqNYjzrlyUlnJ7+UnG6Ax1G7w9H

6tSsH9HqD31gWj/ka9QpLYxu0lDLTkp1igI6PftMhCCVLhUCGgYaXTR8dKh7RE9f

Wbe9XoAgHJBO1asgPKkaStK50qodocF0mUZA3iB9754kbk0AJY9C1E0CNSKsS3X3

eSZg1cSF2hd9hndCSsj8FFTd/P/i799drXQXWx3BBCaVqgEtLGgU0KvgHpirNUPS

A8aYDY/t3x4vnTVv/1iBR0YdM5IwrgPIfrTTzWZ/SBbgpQ4efm9U89t3VGYeFZeP

iB2b0VLAcjKYBjHIGRQj858=

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

MIIE3jCCA8agAwIBAgICAwEwDQYJKoZIhvcNAQEFBQAwYzELMAkGA1UEBhMCVVMx

ITAfBgNVBAoTGFRoZSBHbyBEYWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR28g

RGFkZHkgQ2xhc3MgMiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNjExMTYw

MTU0MzdaFw0yNjExMTYwMTU0MzdaMIHKMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH

QXJpem9uYTETMBEGA1UEBxMKU2NvdHRzZGFsZTEaMBgGA1UEChMRR29EYWRkeS5j

b20sIEluYy4xMzAxBgNVBAsTKmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5j

b20vcmVwb3NpdG9yeTEwMC4GA1UEAxMnR28gRGFkZHkgU2VjdXJlIENlcnRpZmlj

YXRpb24gQXV0aG9yaXR5MREwDwYDVQQFEwgwNzk2OTI4NzCCASIwDQYJKoZIhvcN

AQEBBQADggEPADCCAQoCggEBAMQt1RWMnCZM7DI161+4WQFapmGBWTtwY6vj3D3H

KrjJM9N55DrtPDAjhI6zMBS2sofDPZVUBJ7fmd0LJR4h3mUpfjWoqVTr9vcyOdQm

VZWt7/v+WIbXnvQAjYwqDL1CBM6nPwT27oDyqu9SoWlm2r4arV3aLGbqGmu75RpR

SgAvSMeYddi5Kcju+GZtCpyz8/x4fKL4o/K1w/O5epHBp+YlLpyo7RJlbmr2EkRT

cDCVw5wrWCs9CHRK8r5RsL+H0EwnWGu1NcWdrxcx+AuP7q2BNgWJCJjPOq8lh8BJ

6qf9Z/dFjpfMFDniNoW1fho3/Rb2cRGadDAW/hOUoz+EDU8CAwEAAaOCATIwggEu

MB0GA1UdDgQWBBT9rGEyk2xF1uLuhV+auud2mWjM5zAfBgNVHSMEGDAWgBTSxLDS

kdRMEXGzYcs9of7dqGrU4zASBgNVHRMBAf8ECDAGAQH/AgEAMDMGCCsGAQUFBwEB

BCcwJTAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AuZ29kYWRkeS5jb20wRgYDVR0f

BD8wPTA7oDmgN4Y1aHR0cDovL2NlcnRpZmljYXRlcy5nb2RhZGR5LmNvbS9yZXBv

c2l0b3J5L2dkcm9vdC5jcmwwSwYDVR0gBEQwQjBABgRVHSAAMDgwNgYIKwYBBQUH

AgEWKmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeTAO

BgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBANKGwOy9+aG2Z+5mC6IG

OgRQjhVyrEp0lVPLN8tESe8HkGsz2ZbwlFalEzAFPIUyIXvJxwqoJKSQ3kbTJSMU

A2fCENZvD117esyfxVgqwcSeIaha86ykRvOe5GPLL5CkKSkB2XIsKd83ASe8T+5o

0yGPwLPk9Qnt0hCqU7S+8MxZC9Y7lhyVJEnfzuz9p0iRFEUOOjZv2kWzRaJBydTX

RE4+uXR21aITVSzGh6O1mawGhId/dQb8vxRMDsxuxN89txJx9OjxUUAiKEngHUuH

qDTMBqLdElrRhjZkAzVvb3du6/KFUJheqwNTrZEjYx8WnM25sgVjOuH0aBsXBTWV

U+4=

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

MIIEADCCAuigAwIBAgIBADANBgkqhkiG9w0BAQUFADBjMQswCQYDVQQGEwJVUzEh

MB8GA1UEChMYVGhlIEdvIERhZGR5IEdyb3VwLCBJbmMuMTEwLwYDVQQLEyhHbyBE

YWRkeSBDbGFzcyAyIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA0MDYyOTE3

MDYyMFoXDTM0MDYyOTE3MDYyMFowYzELMAkGA1UEBhMCVVMxITAfBgNVBAoTGFRo

ZSBHbyBEYWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR28gRGFkZHkgQ2xhc3Mg

MiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASAwDQYJKoZIhvcNAQEBBQADggEN

ADCCAQgCggEBAN6d1+pXGEmhW+vXX0iG6r7d/+TvZxz0ZWizV3GgXne77ZtJ6XCA

PVYYYwhv2vLM0D9/AlQiVdw4ytoHUwHU9S3/Hd8M+eKsaA7Ugay9qK7HFiH7Eux6w

wdhFJ2+qN1j3hybX2C32qRe3H3I2TqYf34ggfsqbl2i/ojgC95/5Y0V4evLOtXi

EqITLdiOr18SPaadsfew324ARFmR6jYGB0xUGlcmIbYsUfb18aQr4CUWWoriMY

avx4A6lNf4DD+qta/KFApMoZFv6yyO9ecw3ud72a9nmYvLEHZ6IVDd2gWMZEewo+

YihfukEHU1jPEX44dMX4/7VpkI+EdOqXG68CAQOjgcAwgb0wHQYDVR0OBBYEFNLE

sNKR1EwRcbNhyz2h/t2oatTjMIGNBgNVHSMEgYUwgYKAFNLEsNKR1EwRcbNhyz2h

/t2oatTjoWekZTBjMQswCQYDVQQGEwJVUzEhMB8GA1UEChMYVGhlIEdvIERhZGR5

IEdyb3VwLCBJbmMuMTEwLwLKoiuwelkyhHbyBEYWRkeSBDbGFzcyAyIENlcnRpZmlj

YXRpb24gQXV0aG9yaXR5ggEAMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQAD

ggEBADJL87LKPpH8EsahB4yOd6AzBhRckB4Y9wimPQoZ+YeAEW5p5JYXMP80kWNy

OO7MHAGjHZQopDH2esRU1/blMVgDoszOYtuURXO1v0XJJLXVggKtI3lpjbi2Tc7P

TMozI+gciKqdi0FuFskg5YmezTvacPd+mSYgFFQlq25zheabIZ0KbIIOqPjCDPoQ

HmyW74cNxA9hi63ugyuV+Idr4y54hj+2DzZduCLzrTia2cyvk0/ZM/iZx4mER

dEr/VxqHD3VILs9RaRegAhJd33552TO7ErBBDpqWeCtWVYpoNz4iCxTIM5Cuf

ReYNnyicsbkqWletNw+vHX/bvZ8=

-----END CERTIFICATE-----

Save the file as All-certs.pem.

Launch openssl.exe again and you’ll notice that if you attempt to execute the Cisco instructed command:

pkcs12 -export -in C:\OpenSSL-Win32\bin\All-certs.pem -inkey C:\OpenSSL

-Win32\bin\mykey.pem -out C:\OpenSSL-Win32\bin\All-certs.p12 -clcerts -passin pa

ss:P@ssw0rd -passout pass:P@ssw0rd

… then you will quickly receive the following error:

unable to write ‘random state’ error

To remove this error, simply set the variable as such:

set RANDFILE=C:\OpenSSL-Win32\bin\.rnd

The error should no longer be thrown once the variable is set:

C:\OpenSSL-Win32\bin>set RANDFILE=C:\OpenSSL-Win32\bin\.rnd

C:\OpenSSL-Win32\bin>openssl.exe

OpenSSL> pkcs12 -export -in C:\OpenSSL-Win32\bin\All-certs.pem -inkey C:\OpenSSL

-Win32\bin\mykey.pem -out C:\OpenSSL-Win32\bin\All-certs.p12 -clcerts -passin pa

ss:P@ssw0rd -passout pass:P@ssw0rd

Loading 'screen' into random state - done

unable to load certificates

4216:error:0906D066:PEM routines:PEM_read_bio:bad end line:.\crypto\pem\pem_lib.

c:795:

error in pkcs12

OpenSSL>

The format of the All-certs.pem file has to be in an exact format as shown above or it won’t work.  Failure to format the All-certs.pem file correctly such as not having the right line breaks will throw the error message:

unable to load certificates

4252:error:0906D066:PEM routines:PEM_read_bio:bad end line:.\crypto\pem\pem_lib.

c:795:

The output would look something like the following:

C:\OpenSSL-Win32\bin>openssl.exe

OpenSSL> pkcs12 -export -in C:\OpenSSL-Win32\bin\All-certs.pem -inkey C:\OpenSSL

-Win32\bin\mykey.pem -out C:\OpenSSL-Win32\bin\All-certs.p12 -clcerts -passin pa

ss:P@ssw0rd -passout pass:P@ssw0rd

Loading 'screen' into random state - done

unable to load certificates

4252:error:0906D066:PEM routines:PEM_read_bio:bad end line:.\crypto\pem\pem_lib.

c:795:

error in pkcs12

OpenSSL>

Fixing the All-certs.pem file with errors such line breaks will remove the error and complete the process of generating the All-certs.p12 file:

C:\OpenSSL-Win32\bin>openssl.exe

OpenSSL> pkcs12 -export -in C:\OpenSSL-Win32\bin\All-certs.pem -inkey C:\OpenSSL-Win32\bin\mykey.pem -out C:\OpenSSL-Win32\bin\All-certs.p12 -clcerts -passin pass:P@ssw0rd -passout pass:P@ssw0rd

Loading 'screen' into random state - done

OpenSSL>

The final step for creating the final-cert.pem file does not require any special steps:

OpenSSL> pkcs12 -in All-certs.p12 -out final-cert.pem -passin pass:P@ssw0rd -pas

sout pass:P@ssw0rd

MAC verified OK

OpenSSL>

The final-cert.pem file is what you will use to upload onto the Cisco Wireless Controller to secure the login web page.

Lync 2013 Meeting set up with “My dedicated meeting space (less secure) is missing audio and video options

I recently ran into a problem with a new Lync Server 2013 deployment where Lync Meetings set up with the My dedicated meeting (less secure) option would not provide users with audio and video options:

If the user changes the Lync Meeting Options to A new meeting space (I control permissions) then the audio and video controls will be present:

This was the first time I’ve come across such an issue and after running out of ideas, I went ahead and opened up a case with Microsoft and the response I got was that the issue is usually caused by corruption of user conference ID and one of the ways to fix this is to reset the user’s conference information.  With that information, I went ahead and tried resetting the conference information via the user’s Dial-in Conferencing Settings and PIN management web console:

… quickly verified that the problem went away. The challenge now was that I couldn’t ask all the users in the company to manually do this themselves and after confirming that there isn’t a PowerShell cmdlet to reset this for all users in the company, the only methods were:

#1 – Use an unsupported method by modifying the database as shown in the following blog post:

Resetting default Lync Conference ID’s
http://masteringlync.com/2013/10/10/resetting-default-conference-ids/

#2 – Disable and re-enable the users’ accounts

I read the comments in the blog post for option #1 and was not comfortable with using the method because of the possible consequences down the road so after consulting with the client, they were ok with me using a PowerShell cmdlet to disable and re-enable the user accounts provided that I preserved their contact list.

The following is the command I used to export all the users’ contact list:

Export-CsUserData -PoolFQDN "lyncstd01.contoso.com" -FileName "C:\ContactExports\PoolContacts.zip"

The following are the cmdlets I used to disable and re-enable each user’s account then re-import their contact list:

Disable-CsUser a-tluk@contoso.com

Enable-CsUser -Identity a-tluk@contoso.com -registrarpool "lyncstd01.contoso.com" -SipAddresstype emailaddress -sipdomain contoso.com

Update-CsUserData -Filename "C:\ContactExports\PoolContacts.zip" -UserFilter a-tluk@contoso.com

Update-CsUserData -Filename "C:\ContactExports\PoolContacts.zip" -UserFilter a-tluk@contoso.com -Confirm:$false