Sam.McGeown.co.uk

If you have a Windows Server 2008 box in a workgroup that you require access to one of the admin shares, it can be a little more complicated than with Server 2003. In my case, we had a SQL server on the back end which was trying to access the web server in the DMZ using PSExec.exe to remotely run a process. Executing PSExec and passing the correct credentials failed with “Access is Denied”.

Similarly, when I tried to access the c$, ADMIN$ shares on the server, it would deny me access, and would lock out my admin account when I tried. Creating a separate share would allow me access, but that’s no good for PSExec. To further confuse things, when I accessed the \\server\c$ share from the server, it worked.

Checking the share properties using “net share c$” shows that the settings are all correct, Everyone has FULL access (this is default, it uses NTFS permissions to restrict access):

This issue does not affect domain member servers, I was able to browse to the c$ shares of several Windows Server 2008 servers on the domain.

The problem is caused by UAC and the elevated privileges required to access the administrative shares. This Microsoft KB article (951016) describes the issue in Windows Vista

To better protect those users who are members of the local Administrators group, we implement UAC restrictions on the network. This mechanism helps prevent against "loopback" attacks. This mechanism also helps prevent local malicious software from running remotely with administrative rights.

and the steps to resolve it, open a new PowerShell window as administrator:

New-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -name "LocalAccountTokenFilterPolicy" -value "1" -propertyType dword

A word of caution: this is opening up a security hole and it should only be done with careful consideration of the risks. The need to use PSExec to remotely run a process was an important part of the deployment, however the same result could be achieved using PowerShell remoting. Until it’s tested and we’re ready to deploy that, I’ll be using this method.

Windows Server, Windows Server 2008, Security, Admin Tools Windows Server 2008, Admin shares, UAC, User Account Control, PSExec

I rebuilt an ESX host in my HA/DRS cluster today, following my build procedure to configure as per VMware best practices and internal guidelines. When the host was fully configured and up-to-date, I added it to the cluster and enabled HA and DRS. Then I went to generate some DRS recommendations to balance the load an ease off my overstretched host, but no recommendations were made.

I couldn’t manually migrate any VMs either – it was odd, because both hosts were added into the cluster, and could ping and vmkping each other from the console.

I also received email alerts -

[VMware vCenter - Alarm Host error] Error detected on [HOST] in [Data Center]: Agent can't send heartbeats.msg size: 1266, sendto() returned: Operation not permitted

It turns out that there were slight naming differences between the default VMKernels on each host, which stops communication. Since one VMKernel was named “VMKernel” and the other “VMKernel 2” it stops the migrations, and hence DRS. The hosts would add into the cluster OK, DRS actually showed as “imbalanced” on the Cluster summary screen - it was just DRS and vMotion which wouldn’t work.

With the VMKernels renamed to exactly the same thing, DRS kicked off no problem, as did a manual migration.

So the moral of the story is this; name ALL networks in the same cluster identically. It makes sense when you think that the VM needs to see it’s Virtual Machine Network on each host – why should the Service Console and VMKernel be any different?

VMware ESX 3.5, VMWare, VMware DRS/HA vmware, DRS, HA, cluster, vmotion, vmkernel, heartbeats.msg

This was a bit of an odd one. I was adding a Gateway Server to a newly rebuilt SCOM 2007 R2 Root Management Server when I kept encountering this error:

The certificate specified in the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings cannot be used for authentication.  The error is The credentials supplied to the package were not recognized(0x8009030D).

I followed the Microsoft install and setup guides exactly, and it’s not my first time either – but I’d never seen that one before.

It turns out that it’s a quirk with Certificate Services and how you request your certificate. I used the Certificate Services website on my Server 2003 Enterprise Root Certificate Authority to request the correct certificate, based on the OperationsManager template I created. Crucially, there wasn’t the option to import the certificate to the Machine/Personal certificate store – it went into the User/Personal. This meant that when it came to exporting and then re-importing the certificate, the private key was not correct.

Requesting the certificate through the MMC Certificates Snap-in and restarting the Health Service resolves the issue.

System Center Operations Manager, Certificate Services SCOM, certificates

We run to monitoring systems where I work, the first is HP SIM and the second is Microsoft System Center Operations Manager. Currently, they and their databases all reside on a single rather battered server, “MONITOR1”.

I’ve installed a new SQL Server 2008 server “SQL1” on Windows Server 2008 to take some of the load, and take advantage of the 64-bit OS and SQL installation.

Both servers are part of the domain “DOMAIN”

The process goes something like this:

1. Add the user that SIM runs as to the SQL server logins. For me that’s “DOMAIN\Insight.Manager”
2. Create a new database on SQL1 with exactly the same name as the MONITOR1 database for SIM. Since my 6.x install is an upgraded 5.x install, the database is called “Insight_v50_0_16732390”.
3. Add the SIM user account to the new database with DBO permissions.
4. Stop the HP SIM service on MONITOR1
5. Right click “Insight_v50_0_16732390” on MONITOR1 and Export. Export all the tables to SQL1…and wait a long time for the data to transfer.
6. While you’re waiting, you can edit the following files (c:\Program Files\HP\Systems Insight Manager\Config\) - database.props and database.admin. Change any references for MONITOR1 to SQL1.
7. Once it’s completed, stop the SQL server on MONITOR1 and start the HP SIM services again - fire up the SIM homepage to check everything is running OK.
8. If it all checks out, remove the old database and if it’s no longer needed, uninstall the SQL server too.

SQL Server 2008, Admin Tools HP, SIM, Systems Insight Manager, Database, sql server 2008, migtation

If you see the following cryptic errors when trying to install FCS, then the chances are you need to install the .Net Framework 1.1 AND SP1.

[06/04/2010 10:47:11] Task (Install Collection Server Component)
The following process failed.
Process: C:\Windows\system32\msiexec.exe
Exit code: 1603
Number of tasks completed: [06/04/2010 10:47:12]

Microsoft, Forefront Client Security Forefront Client Security, installation