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

Using PowerCLI to create new role and assign service account used by Citrix XenDesktop & XenApp 7.x service account permissions for vCenter Server 5.1 and 5.5

As demonstrated in one of my previous posts for XenDesktop 5.6:

Using PowerCLI to create new role and assign service account used by Citrix XenDesktop 5.6 permissions for vCenter Server 5.1

http://terenceluk.blogspot.com/2013/04/using-powercli-to-create-new-role-and_9.html

… you can use PowerCLI to create, configure and assign the role required for the XenDesktop service account to access vCenter. This post serves as an update for Citrix XenDesktop and XenApp 7.x environments.

The permissions required for the service account that XenDesktop / XenApp uses to connect to vSphere vCenter can be found at the following URL:

http://support.citrix.com/proddocs/topic/xenapp-xendesktop-76/xad-install-prep-host-vmware.html

The following are the permissions to set for the role if this was to be done manually:

Datastore

• Allocate Space
• Browse Datastore
• Low level file operations

Global

• Manage custom attributes
• Set custom attribute

Network

• Assign Network

Resource

• Assign virtual machine to resource pool

Tasks

• Create task

Virtual Machine > Configuration

• Add or remove device
• Add existing disk
• Add new disk
• Advanced
• Change CPU Count
• Memory
• Remove disk
• Change resource
• Settings

Virtual Machine > Interaction

• Power Off
• Power On
• Reset
• Suspend

Virtual Machine > Inventory

• Create from existing
• Create new
• Register
• Remove

Virtual Machine > Provisioning

• Allow disk access
• Allow virtual machine download
• Allow virtual machine files upload
• Clone virtual machine
• Deploy template
• Mark as virtual machine

Virtual Machine > Snapshot Management

• Create snapshot
• Remove Snapshot
• Revert Snapshot

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

$priv = Get-VIPrivilege -ID

Datastore.AllocateSpace,Datastore.Browse,Datastore.FileManagement,Network.Assign,Resource.AssignVMToPool,Task.Create,VirtualMachine.Config.AddRemoveDevice,VirtualMachine.Config.AddExistingDisk,VirtualMachine.Config.AddNewDisk,VirtualMachine.Config.AdvancedConfig,VirtualMachine.Config.CPUCount,VirtualMachine.Config.Memory,VirtualMachine.Config.RemoveDisk,VirtualMachine.Config.Resource,VirtualMachine.Config.Settings,VirtualMachine.Interact.PowerOff,VirtualMachine.Interact.PowerOn,VirtualMachine.Interact.Reset,VirtualMachine.Interact.Suspend,VirtualMachine.Inventory.Create,VirtualMachine.Inventory.CreateFromExisting,VirtualMachine.Inventory.Delete,VirtualMachine.Inventory.Register,VirtualMachine.Provisioning.Clone,VirtualMachine.Provisioning.DiskRandomAccess,VirtualMachine.Provisioning.GetVmFiles,VirtualMachine.Provisioning.PutVmFiles,VirtualMachine.Provisioning.DeployTemplate,VirtualMachine.Provisioning.MarkAsVM,VirtualMachine.State.CreateSnapshot,VirtualMachine.State.RemoveSnapshot,VirtualMachine.State.RevertToSnapshot,Global.ManageCustomFields,Global.SetCustomField

New-VIRole -Name "XenApp 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 “NetBIOSdomainName\svc_XenDesktop” -Role “XenDesktop Service” -Propagate:$true

$rootFolder = Get-Folder -NoRecursion

Note that the cmdlets above were tested with Citrix XenDesktop 7.6 and vCenter 5.1.0 Build 1364037.

Exchange 2010 federation calendar sharing reports the error: “The attendee’s server couldn’t be contacted. (Error code: 5016)”

Problem

You’ve completed configuring federation for two Exchange 2010 server organizations and begin testing calendar sharing but noticed that users from one of the Exchange organizations displays the following message when viewing free/busy schedule:

The attendee’s server couldn’t be contacted. (Error code: 5016)

Executing the Test-FederationTrust cmdlet on the Exchange Server in the domain that does not appear to be sharing calendar information displays the following errors:

[PS] C:\Windows\system32>Test-FederationTrust -UserIdentity administrator@domainABC.com

RunspaceId : 44741c0c-b08a-4979-abbc-9317481f9307
Id         : FederationTrustConfiguration
Type       : Success
Message    : FederationTrust object in ActiveDirectory is valid.

RunspaceId : 44741c0c-b08a-4979-abbc-9317481f9307
Id         : FederationMetadata
Type       : Error
Message    : The federation trust doesn't contain the same certificates published by the security token service in its
             federation metadata.

RunspaceId : 44741c0c-b08a-4979-abbc-9317481f9307
Id         : StsCertificate
Type       : Success
Message    : Valid certificate referenced by property TokenIssuerCertificate in the FederationTrust object.

RunspaceId : 44741c0c-b08a-4979-abbc-9317481f9307
Id         : StsPreviousCertificate
Type       : Success
Message    : Valid certificate referenced by property TokenIssuerPrevCertificate in the FederationTrust object.

RunspaceId : 44741c0c-b08a-4979-abbc-9317481f9307
Id         : OrganizationCertificate
Type       : Success
Message    : Valid certificate referenced by property OrgPrivCertificate in the FederationTrust object.

RunspaceId : 44741c0c-b08a-4979-abbc-9317481f9307
Id         : TokenRequest
Type       : Success
Message    : Request for delegation token succeeded.

RunspaceId : 44741c0c-b08a-4979-abbc-9317481f9307
Id         : TokenValidation
Type       : Error
Message    : Failed to validate delegation token.

[PS] C:\Windows\system32>

Solution

While there are probably various reasons why the errors above would be thrown, one of the environments I worked with that had this issue was fixed by rerunning the Manage Federation... wizard as such: