Pages

Thursday, June 7, 2012

Disabling access to email, contacts and calendar for Subscriber Access in Exchange 2010

I was asked a few years ago back in the Exchange 2007 days whether it was possible to remove the mailbox functionality from a user but enable them for Unified Messaging so they could have voicemail and after doing a bit of research, I found that you actually can’t because in order to enable a user for UM, you had to enable them for email.  Fast forward to a few years later I have a client with Exchange 2010 who had a small group of users who, by company policy, should only have voicemail but not email and I was asked to prevent them from accessing their email’s inbox via the Unified Messaging Subscriber Access line.  Knowing that I’m bound to come across this again at some point, I thought it would be nice to blog it.

There are actually 2 ways of disabling access to certain mailbox features for users who dial into their Exchange UM’s subscriber access line.  First, the features that are available when a user dials in are as follows:

  • Voicemail
  • Email
  • Calendar
  • Personal contacts
  • Directory
  • Personal options

Other than the Voicemail and Personal options options, all of the other features can be disabled by one or the two of the following methods:

Method 1 – Disable features via per UM Mailbox level

The first method is to disable voicemail subscriber access features by a per UM mailbox level.  The drawback of using this method is that you’ll be executing this cmdlet on every user and you are only limited to disabling:

  • Email
  • Calendar

To execute this cmdlet, open up the Exchange Management Shell and type in the following:

To disable email access –> Set-UMMailbox -Identity “<Mailbox Name>” -TUIAccessToEmailEnabled $true

To disable calendar access –> Set-UMMailbox -Identity “<Mailbox Name>” -TUIAccessToCalendarEnabled $true

The following is an example for disabling Bradley Simons’ email access via the subscriber access line:

Set-UMMailbox -Identity "Simons, Bradley" -TUIAccessToEmailEnabled $true

Method 2 – Disable features via per UM Mailbox Policy

The second method to disable voicemail subscriber access features is through the use of a new UM Mailbox Policy.  The advantage of using another UM Mailbox Policy is that you can disable all of the following features:

  • Email
  • Calendar
  • Personal contacts
  • Directory

**Note that you can associate more than one UM Mailbox Policy to a dial plan.

Begin by creating a new UM Mailbox Policy and executed the following cmdlets to disable the features:

Set-UMMailboxPolicy -Identity "<UM Mailbox Policy Name>" -AllowTUIAccessToEmail $false

Set-UMMailboxPolicy -Identity "<UM Mailbox Policy Name>" –AllowTUIAccessToPersonalContacts $false

Set-UMMailboxPolicy -Identity "<UM Mailbox Policy Name>" -AllowTUIAccessToCalendar $false

Set-UMMailboxPolicy -Identity "<UM Mailbox Policy Name>" -AllowTUIAccessToDirectory $false

To assign users this UM Mailbox Policy, open up the Exchange Management Console, navigate to Recipient Configuration –> Mailbox:

image

Open up the user’s properties, click on the Mailbox Features tab then open up the properties of the Unified Messaging feature:

clip_image001

Click on the Browse button:

clip_image001[4]

… and choose the UM Mailbox Policy:

image

image

Click on the OK buttons to apply the changes.

Relocating Internet Explorer’s temporary internet files in a Citrix XenApp environment with Active Directory GPO

One of the challenges using Citrix XenApp published applications from desktops is when you attempt to open files through Internet Explorer because the Internet Explorer resides on the desktop while the application, such as MS Project, resides on the Citrix XenApp server.  What ends up happening is that the file that’s being opened is temporarily downloaded to the desktop’s temporary internet files folder and the Citrix published application, residing on the server, attempts to reach into the same folder path on its own attached storage to open the file.  So let’s say the temporary internet files location on the desktop is C:\Temporary, the Citrix XenApp server would attempt to open the file on its own C:\Temporary and subsequently fail.  The following is a post I wrote earlier in the week about this:

Unable to launch project files from web pages with Microsoft Project published with Citrix XenApp 6.5
http://terenceluk.blogspot.com/2012/06/unable-to-launch-project-files-from-web.html

As mentioned in the post above, the solution is to simply redirect the Temporary Inter Files folder from the path of the local drive of desktop to another folder that the Citrix XenApp can also access. 

image

Since both the desktop and the XenApp server needs to be able to access the drive with the same name, the logical choice would be to use a folder such as the user’s home drive.  I’ve had mixed results with redirecting the temporary internet files folder to the user’s home drive and have found that the performance can be extremely poor.  One of the more recent tests I’ve done involved MS Project files that were 100KB and 987KB.  The smaller MS Project file opened within reasonable time while the larger file took at least 10 times longer.  This prompted me to go with another solution and that was to redirect the file to a local on the desktop but was also accessible by the server.

Path to Redirect Temporary Internet Files

The choices I usually propose to clients to test are as follows:

Redirect to user’s home drive – the path would be the full UNC path such as \\fileserver\users$\%username%

**Note that you cannot use the %homedrive% variable as the policy we’ll be configuring won’t work as expected.

Redirect to the user’s desktop’s C drive – the first thought I had was to redirect the temporary internet files folder to \\%computername%\users\%username% but this meant that I would need to share out the users folder and some administrators wouldn’t like that so the alternative I usually prefer is to create a folder and share it out so the path would look something like this \\%computername%\TIE.

Group Policy for Redirection

Unfortunately, you won’t find a GPO setting within the Internet Explorer node that will allow you to select a path to redirect the files.  The only way to do it cleanly without using a script is to use the Group Policy Preferences feature provided with Windows Server 2008 R1 or R2 domain controllers (or alternatively a Windows 7 desktop with Group Policy Management tools installed) to edit 2 registry keys.  The reason why I say cleanly is because one of the two registry keys’ value is stored in hexadecimal format which means you can’t simply use a script to fill the value out with a string.  I only have any screenshots that have redirect the path to the user’s home folder so the following example will show that.  If you choose to redirect to a folder on the local computer then modify the path as required.

The 2 registry keys are as follows:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

Cache – Type –> REG_EXPAND_SZ

image

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders

Cache – Type –> REG_SZ

image

These 2 keys can be easily modified via the following Group Policy Preferences GPO:

image

image

clip_image002

Change the Action value to Replace:

clip_image002[4]

clip_image002[6]

Navigate to HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders:

clip_image002[8]

clip_image002[10]

Change the value to the shared path accessible by both the desktop and server of your choice:

clip_image002[12]

Create a second registry item:

image

clip_image002[14]

Change the Action value to Replace:

clip_image002[16]

clip_image002[18]

Navigate to HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders:

clip_image002[20]

clip_image002[22]

Change the value to the shared path accessible by both the desktop and server of your choice:

clip_image002[24]

You should now see 2 registry entries in the policy:

image

Apply this policy to the user object and force a policy update.  Once the policy has been refreshed, you will notice the change in the temporary internet files location the next time you log on.

One of the questions I’ve been asked in the past is how we can automate the task of creating the new folder and sharing it out.  If you’re using this with virtual desktops then the easiest way is to actually modify the master template.  Otherwise, if you’re using physical desktops, then you’ll need to use a script.

Wednesday, June 6, 2012

Exchange 2010 SP1 or SP2 PowerShell cmdlet for deleting all email in a mailbox

I haven’t had to do a whole lot of Exchange 2010 work recently as most of the projects I’ve been involved in were either desktop virtualization or datacenter related but just about a week ago I was asked what the cmdlet was to delete all the mail in an inbox.  I remember executing the cmdlet a while ago and after a bit of digging in my notes, I found it.  Knowing that I’m bound to come across this again, I thought I’d write a short blog on the prerequisites required for setting up the account and finally the cmdlet for future reference.

Prerequisites

The first thing you’ll need to do is ensure that you have given the account you’re going to use the proper permissions by adding them into the following groups:

  1. Discovery Management <—Already Exists
  2. Exchange Support Diagnostics <—Does not exist so you’ll need to create it
  3. Exchange Mailbox Import Export<—Does not exist so you’ll need to create it

Discovery Management

The Discovery Management group is located in the Microsoft Exchange Security Groups OU in your domain:

image

Members of this management role group can perform searches of mailboxes in the Exchange organization for data that meets specific criteria.

clip_image001

Exchange Support Diagnostics & Exchange Mailbox Import Export

The Exchange Support Diagnostics & Exchange Mailbox Import Export groups are not created by default which means you’ll need to manually create them.  The following TechNet blog does a great job of explaining these groups so I won’t reiterate it here:

http://blogs.technet.com/b/exchange/archive/2010/03/26/3409621.aspx

The instructions in the blog above never worked for me as switch:

-Members "<domain\groupname>"

Would cause the cmdlet I execute to continuously fail.  My workaround is to simply omit that switch and add the members with the Active Directory Users and Computers GUI once the group has been created so to create the Exchange Mailbox Import Export group, execute the following cmdlet:

[PS] C:\Windows\system32>New-RoleGroup -Name "Exchange Mailbox Import Export" -Roles "Mailbox Import Export" -DisplayName "Exchange Mailbox Import Export" -Description "This group will provide access to mailbox import and export cmdlets within entire Exchange Organization."

Name                          AssignedRoles                 RoleAssignments               ManagedBy

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

Exchange Mailbox Import Ex... {Mailbox Import Export}       {Mailbox Import Export-Exc... {domain.internal/Microsoft ...

[PS] C:\Windows\system32>

image

To create the Exchange Support Diagnostics group, execute the following cmdlet:

[PS] C:\Windows\system32>New-RoleGroup -Name "Exchange Support Diagnostics" -Roles "Support Diagnostics" -DisplayName "Exchange Support Diagnostics" -Description "This group will provide access to support diagnostics cmdlets within entire Exchange Organization."

Name                          AssignedRoles                 RoleAssignments               ManagedBy

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

Exchange Support Diagnostics  {Support Diagnostics}         {Support Diagnostics-Excha... {domain.internal/Microsoft ...

[PS] C:\Windows\system32>

image

Once those 2 cmdlets have been successfully executed, you should now see the following 2 groups:

image

Proceed with adding the the account you intend on executing the cmdlet to delete the contents in a mailbox into those 2 groups.

Deleting contents of a mailbox

To delete the contents of a mailbox, first obtain the identity of the mailbox by executing the following:

[PS] C:\Windows\system32>Get-Mailbox | where-object {$_.alias -match "tluk"}

Name                      Alias                ServerName       ProhibitSendQuota

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

Luk, Terence              tluk                 svrexmb12        unlimited

clip_image001[4]

Now that you have the identity execute the following cmdlet to delete the content:

**Note that this command deletes all of the mail in the inbox as well as the folders.

[PS] C:\Windows\system32>Search-Mailbox -Identity "Luk, Terence" -DeleteContent

Confirm

Deleting content from mailboxes Luk, Terence

[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"): Y

RunspaceId       : e9269d66-4888-4dd4-96cd-c72e0358e099

Identity         : domain.internal/Domain/Users/CCS/Luk, Terence

TargetMailbox    :

TargetPSTFile    :

Success          : True

TargetFolder     :

ResultItemsCount : 145

ResultItemsSize  : 18.22 MB (19,107,056 bytes)

[PS] C:\Windows\system32>

image

Check the mailbox to ensure that the content has been deleted:

image

Logging onto Citrix NetScaler VPX 1000 access gateway throws the error: “401 - Unauthorized: Access is denied due to invalid credentials.”

Problem

You attempt to log into your Citrix environment through a NetScaler VPX 1000 access gateway:

image

… but receive the following error:

Server Error

401 - Unauthorized: Access is denied due to invalid credentials.

You do not have permissions to view this directory or page using the credentials that you supplied.

image

Logging onto your web interface server shows the following event ID 18001 errors logged:

image

Site path: C:\inetpub\wwwroot\Citrix\XenAppExternal.

A communication error occurred while attempting to contact the Access Gateway authentication service at https://access.someDomain.com/CitrixAuthService/AuthService.asmx. Check that the authentication service is running. The message reported by the underlying platform was: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.. [Unique Log ID: 87cca4b]

For specific information about this message, see the Web Interface documentation at http://support.citrix.com/proddocs/topic/web-interface-impington/wi-log-messages-event-ids-hardwick.html.

image

Solution

One of the reasons why you may encounter this error when logging through the NetScaler VPX 1000 is because the certificate you’re using with the appliance (the NetScaler VPX 1000) is issued by certificate authority that your web servers does not trust.  In this example, the issuing certificate authority for the certificate on the NetScaler is issued by QuoVadis Root CA 2 followed by an intermediate issuing CA QuoVadis Global SSL ICA:

image

As shown in the Local Computer certificate store of the web server, the certificate QuoVadis Root CA 2 is in the Trusted Root Certification Authorities but the certificate QuoVadis Global SSL ICA isn’t:

image

The solution is to simply obtain the certificate you don’t have in your Local Computer’s Trusted Root Certification Authorities and import it:

image

Copy and paste the certificate, open up notepad, paste the content and save it as a .PEM file:

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

MIIFTjCCAzagAwIBAgICBXowDQYJKoZIhvcNAQEFBQAwRTELMAkGA1UEBhMCQk0x

GTAXBgNVBAoTEFF1b1ZhZGlzIExpbWl0ZWQxGzAZBgNVBAMTElF1b1ZhZGlzIFJv

b3QgQ0EgMjAeFw0wNzAxMTIxNjEzMzNaFw0xNzAxMTIxNjEzMTFaMGsxCzAJBgNV

BAYTAkJNMRkwFwYDVQQKExBRdW9WYWRpcyBMaW1pdGVkMR8wHQYDVQQLExZ3d3cu

cXVvdmFkaXNnbG9iYWwuY29tMSAwHgYDVQQDExdRdW9WYWRpcyBHbG9iYWwgU1NM

IElDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKk1mD/CiG1+aGcM

xI7LJL0x4qQpmljkCt1BFL1oaoyuFW4l0GKVTNPFsJ6w4a7pLejG1uQJgeRmKy8n

xm12NXgIshfqBvTqVFAcuGViwCreo5S+oZWlLxTIYRVJZB3OujED5IyXVibMLR7g

xWwcXS2BCSNDUnCAN2x+sGHSR9o4sGTbiYFMZPWZfOc0rIbWtms/cUSVfqneyRGN

WgoIvKPdT2vGvf70RpszxqjEEBLT2A1F2QwM/BxgxylzyelGCN6qVDJrE2rP1KRq

AN+qiV7kK9MphZ9RYRkjtHE3qNkIxTi4KLy/FBWCy9abwK7t8+AGP6y+N8Oxf7Ed

9AU37VcCAwEAAaOCASAwggEcMA8GA1UdEwEB/wQFMAMBAf8wOgYIKwYBBQUHAQEE

LjAsMCoGCCsGAQUFBzABhh5odHRwOi8vb2NzcC5xdW92YWRpc2dsb2JhbC5jb20w

QgYDVR0gBDswOTA3BgRVHSAAMC8wLQYIKwYBBQUHAgEWIWh0dHA6Ly93d3cucXVv

dmFkaXNnbG9iYWwuY29tL2NwczAOBgNVHQ8BAf8EBAMCAQYwHwYDVR0jBBgwFoAU

GoRivEhMMyUE1O7Q9gPEGUbRlGswOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2Ny

bC5xdW92YWRpc2dsb2JhbC5jb20vcXZyY2EyLmNybDAdBgNVHQ4EFgQUMk2hT+rw

rpm27psHLIQIEVCL4n4wDQYJKoZIhvcNAQEFBQADggIBAI5zWxH+LIAvrc/dYIWZ

8zHozDuc1kbd7IaiSgjJCZwNo1vMSLbNfgPg7XIoTDJ903URzDUWh4l8/XncwRil

rRafR23N/iFkM+NF+LoABd9qpF/oAmOGuJ6GwPUf/yhioc8nQ/WXuMVF4/OTdvGF

0QRsk7rivttpGx2aQhGBwO39ft4cySvXToNsBjH4VWcduEooZDg6plIec8S2zrFA

dXvxSgz/sV41QHwyUokTxEY1UoXF9aA5VeGLKIkC1NasTyy26bzuOYOKxgqRUXIu

n6M+CdWiKKJWVi3rBpbnFQWSrsotp4jeQn9zBuovTR0OOijTBWHj9ThxrIG5pb4g

Nmd03/NZDe5l3ja59+UtBUpfCbdqPCCZSUy7t6PLAoDo5JwQKCEOrmNpwD/207GP

2WMo77wh5/mvJRJMFfEZ+CwQXk5LPXXU7EJr+7PYpJB67hryxts1I6FJI0AF3ET9

3YZ4sgEK009h6bdeZbIOvcT4e0v33EAJggFtxU/5xRdtk/PmwxBjSxeg+jBK2xeH

3TScxc6nNvtcw22Lds5GucMsoxmpblYV1adrowg3twQvSXQZ96jzyT3qfmk09M+e

bBTqd3GFwZcJNaQigOw8EQHQtjJm9Zco7FtJ+SxEqcQYFJ+M7QZz+0wWCPwlflMo

7aGlYILpWH4iR3ZhuH/3xMkx

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

image

Proceed with importing it into your Local Computer’s Trusted Root Certification Authorities store:

image

image

image

If you have more than one web interface servers, import the same certificate to the other nodes.  A restart of the servers or NetScaler is not necessary so once you have the certificates imported, test the login again and you should be able to log in:

image

Tuesday, June 5, 2012

Recreating SSL certificate on a Citrix NetScaler VPX 1000 with the private key and CA issued certificate crt file

I’ve come across an issue over the past few months where the SSL certificate issued by a public CA has gone missing due to various reasons and since I had to reference my notes, I thought it would be worth while blogging this in case I ever need to do it again in the future.  As most NetScaler administrators would know, obtaining an SSL certificate issued by a public Certificate Authority requires generating a private key file with the .key extension and a file with the .csr on the NetScaler, submit the CSR file to a public CA, then obtain the .crt file to complete generating the certificate.  All 3 of these files are ultimately copied onto the NetScaler appliance so assuming you haven’t deleted them, all you need to do is open up the Access Gateway VPX’s administrative console, navigate to SSL –> Certificates:

image

Right click on the window on the right and select Install:

image

You will then be presented with the following window:

image

Note the following fields to be entered:

Certificate-Key Pair Name – This is just a logical name you give to the certificate so name it as the name you like.

Certificate File Name – This is the crt file that you downloaded from your public CA after submitting the CSR.

Private Key File Name – This is the .key file that you created when generating a private key for your NetScaler VPX appliance.

Password – This is the password you created during generating the keys.

image

Once you’ve filled out the fields as shown above, proceed by clicking the Install button and you should now see your certificate:

image

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

Note that if you encounter the following error during the install:

Certificate with key size greater than RSA512 or DSA512 bits not supported

image

… it can mean that you have a licensing issue on your NetScaler.  Check the licenses on your NetScaler to ensure none of them are labeled as invalid.

One of the ways to check is to SSH over to the NetScaler VPX, type the following:

shell
cd /var/log
cat license.log

image

Notice how I’m seeing some license errors in the screenshot below:

image