For an Active Directory domain with an enterprise root certification authority, the enterprise root certification authority infrastructure is trusted by all machines that are a member of the Active Directory domain, and therefore any certificates issued by this certification authority are automatically trusted.

In the case of code signing, it may be necessary also for the issued certificate to be in the “Trusted Publishers” store of the local machine in order to avoid any prompts upon executing code, even if the certificate was issued by a trusted certification authority. Therefore, it is required to ensure that certificates are added to this store where user interaction is unavailable, such as running automated processes that call signed code.

A certificate can be assigned to a user or a computer, which will then be the “publisher” of the code in question. Generally, this should be the user, and the user will then become the trusted publisher. As an example, members of the development team in your organisation will probably each have their own code signing certificate, which would all be added to the “Trusted Publishers” store on the domain machines. Alternatively, a special domain account might exist specifically for signing code, although one of the advantages of code signing is to be able to determine the person who signed it.

The processes below details the steps required to generate a code signing certificate, export the certificate and private key, and import the certificate to a local machine or to a group of machines through the use of group policy.

Creating the Code Signing Certificate Template

1. Open the “Certification Authority” console on the enterprise root certification authority
2. Click on “Certificate Templates” and check if a template called “Code Signing” exists (if it already exists, there are no further steps required for this section)
3. If the “Code Signing” template does not exist, right click on the “Certificate Templates” node and select “New” -> “Certificate Template to Issue”
4. Select “Code Signing” and click OK

Generating the Code Signing Certificate

1. Open MMC under administrative context
2. Add the “Certificates” snap-in to the MMC console (select “My user account” when prompted)
3. Expand “Personal”, right click on “Certificates” and select “All Tasks” -> “Request New Certificate”
4. Select “Active Directory Enrollment Policy”
5. Tick “Code Signing” and then click on the “Details” button to the right hand side of the “Code Signing” option
6. Click on “Properties”
7. Click on the “Private Key” tab, and then expand the “Key Options” section
8. Tick “Make private key exportable” and “Strong private key protection”
9. Click OK and then click the “Enroll” button (a message may appear stating that an application is creating a protected item – click OK to acknowledge this message)

Exporting the Certificate for Publishing

1. Open MMC under administrative context
2. Add the “Certificates” snap-in to the MMC console (select “My user account” when prompted)
3. Expand “Personal”, right click on the appropriate code signing certificate and select “All Tasks” -> “Export…”
4. Choose the option “Yes, export the private key” when prompted
5. Accept the default options on the “Export File Format” screen
6. Enter a password for the private key, which will need to be entered when importing the certificate
7. Save the certificate to an appropriate location

Importing the Certificate for Trusting

Local Machines

1. Open MMC under administrative context
2. Add the “Certificates” snap-in to the MMC console (select “Computer account” and select the local machine when prompted)
3. Right click “Trusted Publishers” and select “All Tasks” -> “Import…”
4. Follow the wizard to import the exported certificate, and enter in the accompanying password that was used when the certificate was exported
5. If the certificate is no longer required to be imported by other machines, it is highly recommended that the exported file is deleted  

Group Policy

1. Open the appropriate group policy for editing
2. Expand “Computer Management” -> “Policies” -> “Windows Settings” -> “Security Settings” -> “Public Key Policies”
3. Right click on “Trusted Publishers” and select “Import…”
4. Follow the wizard to import the exported certificate, and enter in the accompanying password that was used when the certificate was exported
5. If the certificate is no longer required to be imported by other machines, it is highly recommended that the exported file is deleted

When you try re-installing WSUS, you get this error: -

"Failed to connect to SQL server

SERVER\MICROSOFT##SSEE

[DBNETLIB]ConnectionOpen (Connect()).]SQL Server does not exist or access

denied."

Additionally, Application event ID’s 17204 & 17207 and System event ID 7024 may also be logged.

Attempts to start the “Windows Internal Database (MICROSOFT##SSEE)” service also fail, as well as attempting to uninstall the Windows Internal Database from Add/Remove Programs.

In order to resolve this issue, you’ll need to follow these instructions: -

1. Open the Registry Editor
2. Expand HKLM\SOFTARE\Microsoft\Microsoft SQL Server\MSSQL.2005\Setup
3. Export all configuration of this key in case a restore is required
4. Remove the “SQLGroup” and “FTSGroup” values
5. Uninstall the Windows Internal Database from Add/Remove Programs
6. Restart the WSUS 3.0 installation

Workarounds have been posted both by McAfee and by the information technology community, however the following might help speed things up if you have a large line of machines to fix by hand: -

1. Download the EXTRA.DAT file from Mcafee here – https://kc.mcafee.com/resources/sites/MCAFEE/content/live/CORP_KNOWLEDGEBASE/68000/KB68780/en_US/EXTRA.zip
2. Copy the EXTRA.DAT file to a USB key
3. Create a batch file with the following content, and save it to the USB key: -

echo off
echo Copying extra.dat…
copy extra.dat “%programfiles%\Common Files\McAfee\Engine”
echo Copying svchost.exe…
copy “%systemroot%\System32\dllcache\svchost.exe” “%systemroot%\System32″
pause
echo Restarting machine…
shutdown -r -t 0

Running this batch file will copy the EXTRA.DAT file in to place, and restore the svchost.exe from the dllcache directory (if it was quarantined) and then automatically restart.

This may not work in all cases, but I have seen a fairly high success rate with machines that I have done this on.

http://technet.microsoft.com/en-us/library/dd347840.aspx

http://technet.microsoft.com/en-us/library/dd637102.aspx

There is another condition that I’ve encountered that causes a Hyper-V guest to report as “Backup Using Saved State” rather than “Backup Using Child Partition Snapshot”, where disks are marked as read-only.

In order to correct this, use diskpart to select the applicable disk and run “attrib disk clear readonly”, and then check that the Hyper-V guest reports as “Backup Using Child Partition Snapshot”.

Unfortunately, I forgot to copy the ACL’s as well, which caused issues when trying to start the virtual machines again. I use System Center Virtual Machine Manager, so when I tried to start my virtual machines again, I got the following error logged in the Jobs log: -

Error (12700)
VMM cannot complete the Hyper-V operation on the server.domain server because of the error: ‘Unnamed VM’ could not initialize. (Virtual machine ID 598AFA1B-1726-44B7-8435-E00B2ACAF2B5)

‘Unnamed VM’ could not read or update the virtual machine configuration because access was denied: General access denied error (0×80070005). Check the security settings on the folder in which the virtual machine is stored. (Virtual machine ID 598AFA1B-1726-44B7-8435-E00B2ACAF2B5)
 (Unknown error (0×8001))

Recommended Action
Resolve the issue in Hyper-V and then try the operation again.

In Hyper-V Manager, the following error is displayed when trying to start the same machine: -

‘SERVER’ failed to start.

Microsoft Emulated IDE Controller (Instance ID {598AFA1B-1726-44B7-8435-E00B2ACAF2B5}): Failed to Power on with Error ‘General access denied error’

IDE/ATAPI Account does not have sufficient privilege to open attachment ‘D:\Virtual Server\Virtual Machines\server\system.vhd’. Error: ‘General access denied error’

 Account does not have sufficient privilege to open attachment ‘D:\Virtual Server\Virtual Machines\server\system.vhd’. Error: ‘General access denied error’

[Expanded Information]
‘SERVER’ failed to start. (Virtual machine ID 598AFA1B-1726-44B7-8435-E00B2ACAF2B5)

‘SERVER’ Microsoft Emulated IDE Controller (Instance ID {598AFA1B-1726-44B7-8435-E00B2ACAF2B5}): Failed to Power on with Error ‘General access denied error’ (0×80070005). (Virtual machine ID 598AFA1B-1726-44B7-8435-E00B2ACAF2B5)

‘SERVER’: IDE/ATAPI Account does not have sufficient privilege to open attachment ‘D:\Virtual Server\Virtual Machines\server\system.vhd’. Error: ‘General access denied error’ (0×80070005). (Virtual machine ID 598AFA1B-1726-44B7-8435-E00B2ACAF2B5)

‘SERVER’:  Account does not have sufficient privilege to open attachment ‘D:\Virtual Server\Virtual Machines\server\system.vhd’. Error: ‘General access denied error’ (0×80070005). (Virtual machine ID 598AFA1B-1726-44B7-8435-E00B2ACAF2B5)

The issue is of course, that because the ACL’s weren’t preserved, Hyper-V can’t read the virtual machine files. Unfortunately, it’s not as simple as just adding the SYSTEM account to the root and applying permissions down, as Hyper-V R2 has it’s own security “namespace” (referred to in Microsoft documentation as the Service SID) called “NT VIRTUAL MACHINE” which contains the GUID’s for all registered virtual machines.

The easiest way to add permissions back to your virtual machines, in order to have them accessible via Hyper-V, is to use the following process on each machine (this is assuming you’re using System Center Virtual Machine Manager): -

• Open the directory that stores your virtual machine
• Open the “Virtual Machines” subdirectory under your virtual machine directory
• Record the GUID as per the file name of the .xml file in this directory
• Run icacls “<virtualmachinefolder>” /grant “NT VIRTUAL MACHINE\<virtualmachineguid>”:F /T (for example icacls “D:\Virtual Server\Virtual Machines\Server” /grant “NT VIRTUAL MACHINE\598AFA1B-1726-44B7-8435-E00B2ACAF2B5″:F /T

Now you should be able to start your virtual machine.

SMS Site Component Manager faild to install component SMS_MP_CONTROL_MANAGER on server myserver.

The WebDAV server extension is either not installed or not configured properly.
Solution: Make sure WebDAV is installed and enabled. Make sure there is an authoring rule that allow “All users” read access to “All content”. Make sure the WebDAV settings “Allow anonymous property queries” and “Allow property queries with infinite depth” are set to “true” and “Allow Custom Properties” is set to false.

Fair enough. I loaded the IIS management console, connected to the local server and opened the “WebDAV Authoring Rules” option. Here, I added a new authoring rule as the error message suggested, and altered the WebDAV settings to specify the advanced properties.

I had made another change that required a restart, so I restarted my server at this stage intending to re-test the management point when it restarted, however the error persisted. I re-checked the authoring rules and properties, and confirmed that they were correct, yet SCCM was still reporting this critical error.

I tracked down the configuration file for WebDAV under “C:\Windows\System32\inetsrv\config\schema\WebDAV_schema.xml” and compared this to the properties I had set via the IIS management console – They didn’t match!

The following section doesn’t line up with what I specified via the IIS management console: -

<attribute name=”allowAnonymousPropfind” type=”bool” defaultValue=”false” />
<attribute name=”allowInfinitePropfindDepth” type=”bool” defaultValue=”false” />
<attribute name=”allowCustomProperties” type=”bool” defaultValue=”true” />

These values should be “true”, “true”, “false”.

I wasn’t able to make any changes to this file without first taking ownership, due to the default ACL’s, but after I did that, I modified the values and re-saved the file (and also reverted the permissions back to the default).

After a restart of the “World Wide Web Publishing Service” and the “SMS_SITE_COMPONENT_MANAGER” service, everything started working correctly.

The only thing I had to do was install the Microsoft Hyper-V Integration Components for Linux on the machine and set the kernel parameters appropriately (as described below).

You can download the .iso from Microsoft at http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=ab7f4983-93c5-4a70-8c79-0642f0d59ec2.

Currently, CentOS/RedHat doesn’t appear to be supported by Microsoft, but following the steps below will allow you to install the appropriate drivers (and confirm a successful intallation): -

• Mount the downloaded .iso on your trixbox machine
• Install the kernel-devel and gcc (GNU Compiler Collection) packages by running the commands below

yum install kernel-devel

yum install gcc

•  Now you’ll need to mount the CD ROM using these commands

mkdir -p /mnt/cdrom

mount /dev/cdrom /mnt/cdrom

• Copy the contents of the CD to the local machine

cp -rp /mnt/cdrom /opt/linux_ic

• Unmount the CD ROM

umount /mnt/cdrom

• Run the driver setup

cd /opt/linux_ic

./setup.pl drivers

• Set the kernel boot parameters as per this article
• You’ll need to restart to initialise the drivers

shutdown -r now

• When the machine is back up and running, make sure the drivers are loaded by running the command below

lsmod | grep vsc

• This should give you a result similar to the following

netvsc

storvsc

blkvsc

vmbus

scsi_mod

Now you have the integration components installed, configure the rest of the options on your trixbox and test it out. I allocated mine 512MB RAM, and it doesn’t skip a beat while I performed audio streaming tests.

While configuring it using the Reporting Services Configuration Manager, under the Database Setup tab I was prompted to upgrade the database version. When I clicked OK, I got the following messages: -

The database version (C.0.8.40) does not match your Reporting Services installation. You must upgrade your Reporting Services database.

And then: -

Couldn’t generate the upgrade script. There is no upgrade script available for this database version.

Which had further details: -

ReportServicesConfigUI.WMIProvider.WMIProviderException: The version does not match a supported version.

Additionally, trying to access the reporting page via my browser gave me this error: -

The version of the report server database is either in a format that is not valid, or it cannot be read. The found version is ‘Unknown’. The expected version is ‘C.0.8.40′. To continue, update the version of the report server database and verify access rights. (rsInvalidReportServerDatabase)

The upgrade was failing because of a version mismatch, and this was caused by the Reporting Services component being installed individually from the SQL core services. The solution was to apply the latest service pack (SP3) to the SQL installation, which re-aligned the versions and allowed the ReportServer database to be upgraded via the Reporting Services Configuration Manager.

This is not a good thing for VoIP, as it relies heavily on time for RTP packet switching.

I also had a compounding issue of my system locking up whenever I tried to perform an NTP update from one of my domain controllers, with an error similar to the following: -

BUG: soft lockup – CPU#0 stuck for 10s! [bash:2513]
EIP: 0060:[<c06100b8>]

dahdi_dummy_timer

It turns out that this service is particularly time sensitive, and the very large time step incurred by an NTP update causes it to lock up until the time is back in phase, but in my case that will never happen because of the rate that the system is gaining time.

My solution was to disable ACPI and APIC at boot time, prevent the dahdi service from starting at runtime and then perform an NTP update and update the hardware clock with the system time by performing the following steps: -

1. Modified the kernel boot options by modifying the boot loader config file (trixbox uses grub, so I had to edit “/boot/grub/grub.conf” to add “divider=10 clocksource=acpi_pm” after the appropriate kernel line
2. Ran “chkconfig dahdi off” to prevent the dahdi service from automatically starting
3. Restart
4. Ran “ntpdate -u <NTP server IP>” to update the time
5. Ran “hwclock –systohc” to update the hardware clock from the system clock
6. Ran “chkconfig dahdi on” to allow the dahdi service to start automatically again

Now the time is accurate and my VoIP calls are working properly.

Log Name:      Microsoft-Windows-Hyper-V-VMMS-Admin
Source:        Microsoft-Windows-Hyper-V-VMMS
Date:          20/09/2009 5:52:42 PM
Event ID:      14050
Task Category: None
Level:         Error
Keywords:    �
User:          SYSTEM
Computer:      HyperV01.mydomain.internal
Description:
Failed to register service principal name.

 I was nearly certain that this was due to the fact that I hadn’t removed the computer from the domain before rebuilding it, and therefore it had acquired the old computer account when it was re-joined. This error indicates that there was an error updating the “servicePrincipalName” attribute of the computer account for my Hyper-V server.

I jumped in to my Active Directory to check out the permissions of the computer account first, and the first thing I noticed was that there was an unresolvable SID in my ACL. This wasn’t causing the issue, but it was a good indication that the permissions were probably in need of attention.

To understand how to resolve this issue, it’s important to understand what’s failing. In this case, we can see from the event 14050, that the SYSTEM account on my Hyper-V host tried to update the servicePrincipalAttribute of it’s own computer account within Active Directory, but failed. We believe it’s a permissions issue, so we should check the “SELF” entry in the ACL to see if it has the correct permissions: -

…And bingo! The “SELF” entry is missing the “Validated write to service principal name” permissions, so therefore it can’t write the attribute. “SELF” in this case, corresponds to the SYSTEM account of the host that owns the computer account.

So I went ahead and granted this permission to the computer account, and confirmed that the servicePrincipalName attribute updated on next attempt and that the events were no longer being logged.