Active Directory, Windows Server

Requesting Web Server certificates from an Enterprise CA

Leave a comment
One of the things I have never been able to figure out, is why you cannot request a certificate based on the Web Server template from a Windows Enterprise CA when you are using the CA web pages (<servername>/CertSrv). Ever since Windows 2000 I have occationally stumbeled on this problem but never had time to really investigate it. I still have not found out why the Web Server template is unavailabe, but I have found a workaround.
By using the certreq.exe utility you can successfully request and receive a certificate from an Enterprise CA. The command you use is:
certreq -submit -attrib “CertificateTemplate:WebServer” <request_file>
The request file is any text file (.cer, .req etc.) that contains the Base64 encoded certificate request generated by your server. Typically a web server. When you run this command you are prompted to select the CA from which you would like to request the certificate and the name of the file in which to save the issued certificate. You can also specify these options on the command line.
Since this works, the problem must lie in the CA web pages. If anyone has an explanations as to what may be the problem I would be very interested.
The reason that I went a little further in trying to crack this problem this time, was that I was setting up my Virtual Server host and was unable to get a certificate for the Virtual Machine Remote Console (VMRC). The administration web pages for Virtual Server cannot send a certificate request directly to an online CA, but rather have to generate a Base64 encoded request which you have to submit to your CA manually and then upload the issued certificate to Virtual Server. Using the above command I was finally able to get a certificate. For those of you wondering; no you cannot use one of the certificates that the computer running Virtual Server has in its certificate store. Virtual Server runs under the Network Serivce account which does not have access to those certificates. Some more information about the exact reason for this is availabe here:
Finally, the SSL certificate for the Virtual Server administration site itself can be retreived in IIS using the request new certificate option.
Exchange Server

Exchange 2007 Autodiscovery and Kerberos

Leave a comment
The Exchange 2007 Autodiscover feature is one of the great imporvements in Exchange 2007. Using Autodiscover, clients can automatically configure their email settings. Outlook 2007 uses Autodiscover through Active Directory, searching for a Service Connection Point (SCP) that identifies all the Client Access servers in the organization. The SCP object, in turns, contains the URL that is to be used in contacting the CAS server to retreive the configuration information. The URL points to a virtual directory called Autodiscover in IIS on the CAS server the SCP objet belongs to.
Autodiscover also works outside the organization. Outlook 2007 and Windows Mobile 6 devices are hard-coded to contact either https://autodiscover.<your email domain>/autodiscover or https://<your email domain>/autodiscover.
Sometimes you want to use the same FQDN for the Autodiscover URL both inside and outside of your organization. This is achieved using the Set-ClientAccessServer cmdlet and its AutoDiscoverServiceInternalUri parameter. There is no external Autodiscover URI parameter, because the external URL will always be the same; autodiscover.<your email domain>.
You have to be careful changing the internal name. After Outlook 2007 finds the URL from the SCP in Active Directory it contacts the URL and authenticates to it using your username and password. The authentication method used is Kerberos. If you change your Autodiscover URL to something with a host name different from the host name of the actual CAS server you will not be able to get the configuration information from the Autodiscover service. You will fail with an Access Denied message, because you cannot successfully authenticate. The reason for this is Kerberos.
When using Kerberos authentication you request and receive a series of tickets from Domain Controllers to access a resource. These tickets are bound to the name of the server hosting the services you want to access, through something called a Service Principal Name (SPN). An SPN is comprised of the service being offered, eg. HTTP or HOST, and the name of the server. A computer’s valid SPNs are listed in the servicePrincipalName attribute on it’s computer object in Active Directory.
If you change the FQDN name in the Autodiscover URL Kerberos will grant a ticket with the wrong SPN and you will be denied access. The soultion to this is to use the SETSPN.EXE utility from the Windows Support Tools to add the new names.
Eg. setspn.exe -A HOST/autodiscover.mydomain.com
After doing this you can reset IIS with the iisreset /noforce command and successfully use your new Autodiscover URL.
Exchange Server

Yet another (unannounced) Transporter Suite update

Leave a comment
A new version of the Transport Suite for Lotus Domino has appeared on the Microsoft download site:
The vesion number is listed as 08.01.0223, and the file size of the transporter.msi file has also changed. Like last time this was not announced and no information exists about what changes have been made.
I am in the middle of a migration project and this is very frustrating. The Trasnporter team should provide updated release notes when htey change their bits. This is the worst version control, or lack thereof, I have ever seen in a professional product.
UPDATE: A recent KB article sheds some light on one of the changes in this newest version of the Transporter Suite. It is a change to fix the problem with foreign language characters not being displayed correctly after a mailbox has been migrated. The KB article is called Foreign characters in e-mail messages are not displayed correctly after you use Microsoft Transporter Suite for Lotus Domino to migrate a mailbox to Exchange Server 2007 and is available here:
Windows Server

Exploring certificates in IIS

Leave a comment
Recently, I’ve been having some issues with certificates in IIS 6.0 that have cause me to perform some operations that I do not normally do. That has taught me a thing or two about certificates in IIS and I have discovered some nice info which I link to in this post.
First off is my discovery that you can actually install a certificate in IIS after you have delete then pending request from ISM. The procedure is described here:
Install certificate after deleting the pending certificate request (IIS 6.0)
The second thing is a KB article that describes how to request a new certificate for a website on a server that already has a certificate, without removing the existing certificate. This is useful if you want to change the identity on the certificate, but not delete your existing certificate right away or cause downtime. The problem here is that you need the private key in the certificate store on the server where you already have a certificate. The procedure is described here:
How To Renew or Create New Certificate Signing Request While Another Certificate Is Currently Installed
Exchange Server

Exchange 2007 Edge servers and Microsoft Networking services

Leave a comment

I had an interesting experience today. I was setting up an Exchange Edge server for a customer. After configuring the TCP/IP settings I proceeded to the Exchange Management Console to enter the server’s product key. I had already prepared the server earlier, installing Exchange and all required patches. But when I selected Properties on the Edge server this error popped up:

An error happened while accessing registry of the specified server: “<server FQDN>“. The error
message: “The network path was not found.”
It was running the command ‘get-exchangeserver –Status –Identity ‘<Administrative Group GUID>‘

I thought this was very strange since I was managing the server locally and not over the network. I remembered that Exchange has a history of requiring the Remote Registry service for various management and installation operations, even if you are managing a server locally and installing Exchange from the console. That service was running, so that was not it in this case. But then it struck me, if Exchange requires the Remote Registry service when performing local operations, it follows that it uses the network redirector to access itself, and in turn the server service to communicate with the Remote Registry service. I immediately brought up the configuration settings for my network card and found the cause of the error. Earlier when I had configured the TCP/IP settings I had removed the bindings for Client for Microsoft Networks and File and Printer Sharing for Microsoft Networks. I did that because these services were not needed for a server that was only supposed to communicate using SMTP, LDAP and RDP, or so I thought. After enabling the bindings again the error disappeared and the server is now functioning normally.

It seems strange that Exchange depends on using the Remote Registry service to perform local operations, especially on an edge server where enabled services should be kept at a minimum. I believe that it lets the programmers implement only one way of administering Exchange; through the Remote Registry service. Otherwise they would have to create two interfaces, one for remote admin and one for local.

Exchange Server

Update to Microsoft Transporter Suite for Lotus Domino

Leave a comment

Evidently the Transporter team has released an updated version of the Microsoft Transporter Suite for Lotus Domino. I can find no updated release notes or any information about any changes. Then only evidence of an update is the size of the installer and the version reported by the management console.

Old version:

041107_0911_UpdatetoMic1

New version:

041107_0911_UpdatetoMic2

The old Transporter.msi file has a size of 8638 KB and the new one has a size of 8685 KB, in Explorer.

You are not allowed to update your current installation, but rather have to uninstall your old version first. Seems strange to me.

You can download the new version from this link:

http://www.microsoft.com/downloads/details.aspx?familyid=35FC4205-792B-4306-8E4B-0DE9CCE72172&displaylang=en#filelist

Another peach of circumstantial evidence appears on this page; the publishing date is 05.04.2007. The original version of Transporter was released on 15.02.2007 (Valentine’s Day).

Hopefully more info about what has been fixed/updated will be available soon.

System Center

SMS 2003 Remote Assistance Configuration

Leave a comment

Microsoft Systems Management Server 2003 enables you to configure the Remote Assistance settings of Windows XP or Windows Server 2003 computers. This article describes the details of how this is done.

Remote Assistance is a technology in Windows XP Professional and Windows Server 2003 that enables users to help each other over the network. With this tool, a support professional can view the desktop of a user, while the two people communicate through a chat box. With the user’s permission, the support professional (helper) can even share control of the user’s computer to resolve issues remotely. With Remote Assistance, a help desk can assist users on the network, which is known as the Offer Remote Assistance feature.

Remote Assistance also enables administrators and support personnel to offer assistance to their users without requiring the users to initiate the Remote Assistance session. This capability is called Unsolicited Remote Assistance. It is disabled by default and can only be enabled using either an unattended.txt file during setup, with Group Policy or through SMS; which this article is about.

SMS 2003 uses Local Group Policy to configure settings on its clients.

Configuration of the client agents in SMS 2003 Administrator

General Tab

022407_1417_SMS2003Remo1

The settings in the red square are the ones pertaining to Remote Assistance.
The ‘Enable Remote Tools on clients’ setting does not need to be checked for SMS to configure Remote Assistance on its clients.

Manage Remote Assistance settings
Select this to have SMS control clients’ settings for Remote Assistance.
If this setting is selected the information on the Security and Policy tabs are propagated to the clients using Local Group Policy.

Override Remote Assistance user settings
Select this to have SMS settings for Remote Assistance override the Remote Assistance settings on the clients.

Security tab

022407_1417_SMS2003Remo2

These settings apply to both SMS Remote Tools and Remote Assistance.

Use this tab to select non-administrator users or groups that will be able to remotely access clients running Windows NT 4.0 or later. Members of the local Administrators group on clients can access the client remotely regardless of whether they are listen in the Permitted Viewers list.

Policy tab

022407_1417_SMS2003Remo3

Here you select the level of access that the helper (support professional or administrator) has over the session. There are three alternatives:

  • Full control
  • Remote Viewing
  • None (disables Remote Assistance access)

Results on the client

Now let’s see how these setting are applied to a client.

022407_1417_SMS2003Remo4

Here you can see the location of the settings that are changed in the Local Group Policy Object on the client. Both of these setting are set to Not Configured by default, but are changed when you select to have SMS control the Remote Assistance setting on the clients.

The ‘Offer Remote Assistance’ setting controls Unsolicited Remote Assistance.

If you select to have SMS control the Remote Assistance settings (Manage Remote Assistance) it sets this policy to Enabled on the next policy refresh. I then sets the remote control level that you specified on the Policy tab in SMS. In this case we selected Full in SMS and the setting in Local Group Policy is ‘Allow helpers to remotely control the computer’, which is the same level. Furthermore SMS sets the Permitted Viewers from the Security tab in the list of allowed helpers in Local Group Policy:

022407_1417_SMS2003Remo5

022407_1417_SMS2003Remo6

From Ed Hammonds SMS pages:

If you uncheck the Remote Assistance boxes in the Remote Tools client config and update the policy this will leave the policy as-is. It does not return it to default. Recheck the RA boxes and then turned off RA from the Policy tab, wait for the CCM cycle and then SMS will disable Remote Assistance in the local policy. Uncheck RA boxes again so that settings made on the client will not be overwritten by SMS. The local policy stays at the last known setting until it is set locally to un-configured or is superseded by a Domain/OU GPO.

Exchange Server

Exchange 2007: Unable to log on to Outlook Web Access “A problem occurred while trying to use your mailbox. Please contact technical support for your organization.”

Leave a comment

When you try to log on to Outlook Web Access in Exchange 2007 you can successfully enter you username and password, but when you select your language and time zone and press OK you receive this error:

022207_2055_Exchange2001

The complete text of the message reads:

Request
Url: https://<fqdn>:443/OWA/lang.owa
User host address: 172.16.1.25

Exception
Exception type: Microsoft.Exchange.Data.Storage.StoragePermanentException
Exception message: There was a problem accessing Active Directory.

Call stack
Microsoft.Exchange.Data.Storage.ExchangePrincipal.Save()
Microsoft.Exchange.Clients.Owa.Core.RequestDispatcher.DispatchLanguagePostLocally(OwaContext owaContext, OwaIdentity logonIdentity, CultureInfo culture, String timeZoneKeyName, Boolean isOptimized)
Microsoft.Exchange.Clients.Owa.Core.RequestDispatcher.DispatchLanguagePostRequest(OwaContext owaContext)
Microsoft.Exchange.Clients.Owa.Core.RequestDispatcher.PrepareRequestWithoutSession(OwaContext owaContext, UserContextCookie userContextCookie)Microsoft.Exchange.Clients.Owa.Core.RequestDispatcher.InternalDispatchRequest(OwaContext owaContext)Microsoft.Exchange.Clients.Owa.Core.RequestDispatcher.DispatchRequest(OwaContext owaContext)System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Inner Exception
Exception type: Microsoft.Exchange.Data.Directory.ADOperationException
Exception message: Active Directory operation failed on apl-dir4.APL-NET.LOC. This error is not retriable. Additional information: Insufficient access rights to perform the operation. Active directory response: 00002098: SecErr: DSID-03150A45, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0

Call stack
Microsoft.Exchange.Data.Directory.ADSession.AnalyzeDirectoryError(PooledLdapConnection connection, DirectoryRequest request, DirectoryException de, Int32& retries, Int32 maxRetries)
Microsoft.Exchange.Data.Directory.ADSession.ExecuteModificationRequest(ADRawEntry entry, DirectoryRequest request, ADObjectId originalId)
Microsoft.Exchange.Data.Directory.ADSession.Save(ADObject instanceToSave, IEnumerable`1 properties)
Microsoft.Exchange.Data.Storage.ExchangePrincipal.Save()

Inner Exception
Exception type: System.DirectoryServices.Protocols.DirectoryOperationException
Exception message: The user has insufficient access rights.

Call stack
System.DirectoryServices.Protocols.LdapConnection.ConstructResponse(Int32 messageId, LdapOperation operation, ResultAll resultType, TimeSpan requestTimeOut, Boolean exceptionOnTimeOut)
System.DirectoryServices.Protocols.LdapConnection.SendRequest(DirectoryRequest request, TimeSpan requestTimeout)
Microsoft.Exchange.Data.Directory.PooledLdapConnection.SendRequest(DirectoryRequest request, LdapOperation ldapOperation)
Microsoft.Exchange.Data.Directory.ADSession.ExecuteModificationRequest(ADRawEntry entry, DirectoryRequest request, ADObjectId originalId)

Cause

This error is caused by incorrect permissions on the user object in Active Directory.

Resolution

Enable inheritance of permissions on the user’s object. This is done in Active Directory Users and Computers, on the advanced tab of the user object. Select the checkbox “Allow inheritable permissions from the parent to propagate to this object and all child objects. Include these with entries explicitly defined here.”

More info

The option to inherit permissions from parent objects will be removed if the user object is, or has ever been, a member of one of the protected groups in Active Directory. These groups include Administrators, Account Operators, Server Operators, Print Operators, Backup Operators, Domain Admins, Schema Admins, Enterprise Admins and Cert Publishers.

More info here:

XADM: Do Not Assign Mailboxes to Administrative Accounts
http://support.microsoft.com/kb/328753

 

Exchange Server

Exchange 2007: Exploring Global message size restrictions

Leave a comment

Exchange 2003

In Exchange 2003 you set the global message size restrictions are set with Exchange System Manager under Global Settings, Message Delivery:

022207_2052_Exchange2001

These settings are written to the Message Delivery object in the configuration partition in Active Directory. The object has the distinguished name (DN):

CN=Message Delivery,CN=Global Settings,CN=<org name>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain>,DC=<domain>

022207_2052_Exchange2002

The attributes written are the following:

GUI Name

Active Directory Attribute

Sending message size

submissionContLength

Receiving message size

delivContLength

Recipient limits

msExchRecipLimit

Exchange 2007

In Exchange 2007 these settings are set using the Set-TransportConfig cmdlet. To view the settings you use the Get-TransportConfig cmdlet:

022207_2052_Exchange2003

These settings are written to the Transport Settings object in Active Directory. The object has the following DN:

CN=Transport Settings,CN=<org name>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain>,DC=<domain>

The same attributes are used but on a different object.

PowerShell Name

Active Directory Attribute

MaxSendSize

submissionContLength

MaxReceiveSize

delivContLength

MaxRecipientEnvelopeLimit

msExchRecipLimit

Exchange 2007 comes with a setting of ‘unlimited’ for all these values.

Co-existence

As mentioned, Exchange 2007 uses ‘unlimited’ as the default setting. But there are a few situations where these limits do not work as expected.

These situations are:

  • If you have both Exchange 2003 and Exchange 2007 servers in your Exchange organization
  • If you previously had Exchange 2003 and are now running Exchange 2007, and had a period of co-existence between the two systems.
  • If you previously had Exchange 2003 and are now running Exchange 2007, but have not had co-existence between the two systems.

If you have been in one of these situations it is a good chance that your global message limits are not working as expected. The reason for this is that if the Exchange 2007 Transport Configuration is set to unlimited, the Exchange 2007 store will read the old Exchange 2003 value. This means that if your Exchange 2003 value is set to 10 MB and the Exchange 2003 value is set to unlimited, you actually have a global message limit of 10 MB.

The situations when this might occur are listed above, and the reason is that the value is set in different places in Exchange 2003 and 2007 and may be “left behind” when you remove Exchange 2003. Or may have been left behind when you removed Exchange 2003.

Workaround

To fix this issue when you are in a co-existence situation, make sure the two values are synchronized. Set them to the same value using ESM for Exchange 2003 and the Set-TransportConfig cmdlet for Exchange 2007. When you are ready to remove Exchange 2003 completely, set the limits in ESM to unlimited. This is the same as Not Set in Active Directory, meaning no vale to read. That way there is no vale for the Exchange 2007 store to read and it uses the Transport Config value, whatever it is set to (including unlimited).

If you already have removed Exchange 2003 and are experiencing this problem, use ADSI edit to remove the values from submissionContLength, delivContLength and msExchRecipLimit on the Message Delivery object in the Configuration partition. Exchange 2007 will now heed the Transport Config values.

Microsoft is planning to resolve the problem with the Exchange 2007 store reading the old value in Service Pack 1 for Exchange 2007.

Note: There are also several other message size limits defined in Exchange 2003 and Exchange 2007. Connectors, users, SMTP Virtual Servers can also have limits. The limits discussed here are the global message limits.

Some more info here:

http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=943981&SiteID=17

Windows

Nice tricks with the context menu in Windows Vista

Leave a comment

For a long time, we have been enjoying a Windows XP Power Tool called “Command prompt here” on our directories’ and drives’ context menus. I recently discovered that Windows Vista has this functionality build in.

If you right-click your directory or drive while you press the SHIFT key, you get a few more choices. One of them is Open Command Windows Here. You also get Copy As Path which copies the path of the folder or drive to the clipboard. That is also very nice.

I wanted to have the command line available at all times so I had to do some digging in the Registry. The paths for the context menu actions for a directory and drive are the following:

Directory:
HKEY_CLASSES_ROOTDirectory
Drive:
HKEY_CLASSES_ROOTDrive

Under these you will find the shell key, it contains all the context menu actions associated with the drive or directory objects. E.g. cmd for command prompt, find for Search etc. The first thing to notice is that the cmd action is already there, so why isn’t it showing up all the time?

022207_2050_Nicetricksw1

The answer is the value you will find under the cmd key kalled Extended. If this value is present the action will only show up if you hold down the SHIFT key while you right-click. We want the prompt available at all times so we go ahead and delete the Extended value from both the Directory and Drive keys. Now the option is always available.

But what if we want an elevated prompt in the directory? We are all, of course, running User Account Control so we need to elevate to enable our Administator privileges when we need them. To have the option to open an elevated command prompt for your drives or directories we need to take some additional steps.

First we need a copy of cmd.exe, the command line program that we will set to always run elevated. Go to your system32 folder and create a copy of cmd.exe that you call cmd_elevated.exe or a name of your choice. Then select the properties for this new file and select that it should always run as an administrator.

022207_2050_Nicetricksw2

Next, you export the cmd action from the Directory and Drive keys in the registry. We are now going to create a new action that will launch the elevated command prompt. First merge the two exported registry files into one so that you can easily import both changes. Then you need to change the alias of the command so that our new item does not overwrite the old normal command prompt. The old alias is cmd, call the new one cmd_elevated or something. You will then have a file that looks like this:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOTDirectoryshellcmd_elevated]
@=”Open Command Window (Elevated) Here”
“NoWorkingDirectory”=””
[HKEY_CLASSES_ROOTDirectoryshellcmd_elevatedcommand]
@=”cmd_elevated.exe /s /k pushd “%V””
[HKEY_CLASSES_ROOTDriveshellcmd_elevated]
@=”Open Command Window (Elevated) Here”
“NoWorkingDirectory”=””
[HKEY_CLASSES_ROOTDriveshellcmd_elevatedcommand]
@=”cmd_elevated.exe /s /k pushd “%V””

Notice that the Extended key is missing from both the actions, that is so that the option will always appear. Now you can import the file and you will have two shiny new options whenever you right-click a drive or directory:

022207_2050_Nicetricksw3

Information wants to be free!