Thursday 21 August 2008

Powershell v2, Vista and Proxy

I have recently downloaded Powershell v2 (CTP) and WinRM 2.0 (CTP) to attempt some Windows PowerShell (Exchange server) remote management. Having installed both components on my Windows Vista machine I attempted to create a runspace and connect to the remote host in powershell using the following synatax;

$rs = New-Runspace -Shell Microsoft.Exchange -ConnectionUri https://remoteserver.com/powershell/ -Credential $MyCred -Authentication Basic

When attempting the connection it would fail with this error message;

New-Runspace : [remoteserver.com] The client cannot connect to the remote host specified in the request. Verify that the service on the remote host is running and is accepting requests. You may use the following command to analyze the state of the WinRM service and to configure the service, if necessary: "winrm quickconfig".

I spent some (ok, quite a lot of) time trying to troubleshoot this. After confirming I could resolve remoteserver.com via DNS, I attempted to PING remoteserve.com. This failed,but of course this could be expected if ICMP is being blocked (I do not own the remote server or firewalls). I then downloaded and used Portqry.exe to see if I could connect to port 443 on myserver.com which failed also.

Now this got me thinking. My Windows Vista workstation uses a proxy server here in my company to access the internet. I wonder if this Powershell runspace is attempting to connect to the internet directly. Remembering the heartache caused by Exchange 2007 services attempting to do this, I attempted to find Proxycfg on my Vista machine. Of course I could not find Proxycfg as it has been dropped in Vista. It has been replaced by extended Netsh functionality. After some Google'ing I have found the correct syntax for Netsh, as follows from a command line;

>netsh
>winhttp
>show proxy


I can now see that there are no winHTTP proxy settings

>set proxy myproxyserver.internal:8080
>show proxy


I have now set the winHTTP proxy server, achieving the same as running Proxycfg -u on previous versions of windows.

My Powershell remote runspace now works. (Interestingly Portyqry still shows the remote server on 443 as FILTERED, but hey - it set me on the right track!)

Monday 11 August 2008

HMC 4.5, DomainCacheTask Scheduled Task

I have found several more small configuration issues with the deployment instructions for HMC 4.5. Again, after finding no relevant resources on the Internet about this small issue I thought I would blog it here to hopefully help someone else.

When attempting to create the SMTP Domain Cache scheduled task the instructions give you the following syntax to run against the Schtasks command in Windows Server 2008.

schtasks /create /S localhost /U %USER% /P %PASSWORD% /SC MINUTE /MO %MINUTES% /TN SmtpDomainCacheTask /TR "\"C:\Program Files\Microsoft Hosting\Provisioning\SmtpDomainCacheTask\SmtpDomainCacheTask.exe\""

When I run this command (replacing %USER%, %PASSWORD% and %MINUTES%, I received the following error message; ERROR: User credentials are not allowed on the local machine.. Of course Google is my first stop for all unknown error messages, and again I found no documentation referring to this error.

To be entirely honest, as Windows Server 2008 is still new to me I had to go and research the Schtasks syntax and switch options. From what I understand the /U and /P switches are more appropriate for when you are scheduling a task on a remote machine and are therefore passing credentials to allow you to create the scheduled task. If I understand the Note: The user account must have write permission to the directory of CategorizerOverrideAgent.dll, and have read permission to MPS PlanManager database. I believe what is actually required is the user context in which you want to run the task. Therefore the switches required are /RU and /RP.

schtasks /create /S localhost /RU %USER% /RP %PASSWORD% /SC MINUTE /MO %MINUTES% /TN SmtpDomainCacheTask /TR "\"C:\Program Files\Microsoft Hosting\Provisioning\SmtpDomainCacheTask\SmtpDomainCacheTask.exe\""

This command now schedules correctly for me.

Friday 8 August 2008

HMC 4.5, Install and Configure the OOF Agent

Whilst installing HMC 4.5 I have now reached the Install and Configure the OOF Agent section. There are some minor details that upset my installation. After some searching of the internet I have realised there is literally no resource or documentation on the web about these components, so I have decided to blog todays findings. (Try entering CategorizerOverrideAgent into Google - I only got one website returned; Technet)

In the section when you install the CategorizerOverrideAgent.msi from the Service Provisioning\MPS\Install folder the instructions state that this should be installed in the C:\Program Files\Microsoft\Exchange Server\TransportRoles\Agents\CategorizerOverrideAgent directory. By default my installation always reverted back to Program Files (x86) not the Program Files folder. I tried to change this several times with no success. It turns out this is not an issue though.

During the steps of installing the categorizer agent via the Exchange Management Shell the steps are not quite in the correct order and some syntax is missing. Rather than just running the switch -AssemblyPath CategorizerOverrideAgent.dll you need to pass it the full path to the dll as the Exchange Management Shell does not know the location of CategorizerOverrideAgent.dll.

In my environment I was not able to run the Enable-TransportAgent CategorizerOverrideAgent cmdlet whilst the MSExchangeTransport service was stopped (as the instructions suggested). I had to start the MSExchangeTransport service, enable the CategorizerOverrideAgent and then restart the service.

Running Get-TransportAgent at the end showed that despite all these annoyances the Categorizer Agent is now installed and enabled on my Hub Transport server.

Thursday 7 August 2008

HMC 4.5, Exchange Resource Manager

I am working may way through deploying Hosted Messaging and Collaboration 4.5 (HMC 4.5). I have reached the point (with a lot of frustration and time consuming tweaks) of configuring Exchange 2007 SP1 Resource Management on the Microsoft Provisioning Engine server. Now if you follow the link here http://technet.microsoft.com/en-us/library/cc501402.aspx you would think this was a fairly straight forward task? Wrong...
So I changed the required values and entered my mailbox, my public folder mailbox and my Domain Controllers FQDN. When I ran the provtest command I received the following error;

errorContext description="Mail server not found"

After trying to troubleshoot this for quite some time it turns out that I made that mistake of using a FQDN. It seems that unless these values are NETBIOS names, the script will fail. Seems ridiculous to me. Hopefully this post might save someone else the time and frustation I spent on this daft issue.

Tuesday 5 August 2008

VMWare Infrastructure Client, mounting ISOs

I am working quite a bit with VMWare Infrastructure Client 2.5 to connect through to my ESX enviornment. I thought I would make a quick post about the frustation of mounting (some) Iso images. I have the following error message when attempting to some mount ISOs across the network for their virtual guests; "Please specify a valid image"

Now that is a very descriptive error message, with not a lot of help, eh? I know the image is fine as I am able to access it via WinIso and I am able to burn DVDs from it. The answer is one or both of the following problems;

1. The file extension was .ISO rather than .iso. Apparently VMWare Infrastructure Client does not like the ISO file extension to be in upper case, so it needed to be renamed to .iso

2. The file name of the ISO was too long. By default the ISO images you download from Microsoft Technet are in a very long format (6001.18000.080118-1840_amd64fre_Server_en-us-KRMSXFRE_EN_DVD.iso) and the VMWare Infrastructure Client does not like this length, rename it something smaller.

After performing one or both of the adjustments above, the ISO image mounts with no issues.

Proxycfg.exe

I originally came across Proxycfg.exe after installing one of the Exchange 2007 Update Rollup packs. Some of the Exchange 2007 services would not start up, in particular the Microsoft Exchange Service Host service.

I have now came across the exact same issue with Microsoft SQL Server 2005 and the SQL Server Integration Services service also.

This problem occurs because the server cannot reach the following Microsoft Web site: http://crl.microsoft.com/pki/crl/products/CSPCA.crl .For some reason these services do not know how to access the Internet if the server is configured to use a Proxy server.
There are various solutions for each individual service that cannot start that involve installing (many) updates to stop these services attempting to reach this site. Alternatively the easiest way to solve this is configure the server services to use the logged on users proxy configuration. To do this open a CMD prompt and change the directory to C:\Windows\System32 and run the command proxycfg.exe -u. In my case the services affected by this problem then all started immediately.

Windows 2008 Active Directory, missing tool

I have just discovered that my favourite Active Directory troubleshooting tool Replmon.exe has not made it to Windows 2008! (replmon technet link)
Here is a quote from a Technet blog;

"Unfortunately, replmon did not survive the transition to Win2008. It was actually developed by MS support, not the product group (along with many other support tools/resource kit tools), and without an actual owner to service the tool years later, it was a casualty."

The Windows 2003 version of Replmon appears to work okay though. You will need to install the Windows 2003 Support Tools (Suptools.msi)ignoring the Program Compatibility Assistant warning This program has known compatibility issues.

Let's just hope those compatibility issues do not cause instability issues on my server then!....