Monthly Archives: February 2007

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

Windows

Zone Information for downloaded files and NTFS Alternate Data streams

Leave a comment

Since Windows XP Service Pack 2 was launched, every time you try to run or open a file that has been downloaded from the Internet, or more correctly, from the Internet Zone in Internet Explorer. You are prompted with the following warning message:

 022207_2051_ZoneInforma1

What this message does, basically, is to warn you that you are opening a file that is downloaded from an un-trusted location. You can see further evidence of this if you view the file’s properties:

 022207_2051_ZoneInforma2

Notice the Unblock button on the lower right. If you select it, the next time you try to open the same file you see no warning. Somehow, by pressing Unblock, you have told Windows that you want to allow this particular file, even if it is from the Internet. But where is this information stored? I searched in all the places I could think of; attributes, DACLs, SACLs, details. What prompted me to do this was that I wanted to unblock several file and was looking for a command line utility to do it. Not even Google knew where this information was stored.

The reason I wanted a command line tool was this. If you download an archive from the Internet and then extract the files in it before you unblock it, all the extracted files are also marked as coming from the Internet and require individual unblocking.

When I attended Tech Ed IT Forum last week in Barcelona I asked Microsoft Security Guru Steve Riley about this, and, not surprisingly, he knew the answer. The information is stored in an NTFS alternated data stream!

NTFS alternate data streams are a little known feature of the NTFS file system, and have been available since Windows NT 3.1. This feature allows you to store data of any kind in an alternate location within a file. When we use files normally we are accessing stream 0. When you open an EXE file or a DOC file you are reading stream 0 of that file. But as I said, you can add several more streams. A while back, ADSs was the cause of a security scare. Someone had read about ADS and found them to be a security risk. What if a malicious user stored a virus or malware in an ADS? The user and all his anti-virus and anti-malware software, would be oblivious! As it turned out, this quickly blew over and now several anti-virus/malware packages scan for the presence of ADSs within files.

So how does this apply to files from the Internet? Consider this example; you have a file you have downloaded from the Internet. In my case it is called daemon408-x86.exe and is the installer for Daemon Tools. When I try to run this file I receive the warning mentioned earlier. Now that I know that this is caused by an alternate data stream I can use a tool to view and delete that stream. There are several tools available, but I chose streams from SysInternals. This is the output from streams for my file:

 022207_2051_ZoneInforma3

As you can see, this file has an ADS called Zone.Identifier:$DATA. To see what it contains we use the more command, which is part of Windows.

 022207_2051_ZoneInforma4

This is the raw data that is stored in the additional stream. Not very much in this case, just two lines of text. But this is what Explorer looks for when you ask to open a file.

To delete this additional stream so that the file opens without warning we again use streams from SysInternals.

 022207_2051_ZoneInforma5

If you want to know more about NTFS Alternate Data Streams, check out these links:

You can download the streams tool from the SysInternals site:

http://www.microsoft.com/technet/sysinternals/Utilities/Streams.mspx

Until next time!