Fixing SMS Site Component Manager could not access site system. Access is denied. Issue when adding SCCM components to other servers.

I recently decided to move our reporting services running on our SCCM site server to our more beefier SQL Server, I was also wanting to do this for our Forefront Migration (as Reporting services is a requirement). So I created a new server under Site Settings -> Site Systems and put our SQL server into there. I then added the ConfigMgr Reporting Point and Reporting services point with SCCM adding in Component Server and Site System into the roles.

After a little while I then checked the Site Component Manager logs and found the following error:

SMS Site Component Manager could not access site system "<servername>".
The operating system reported error 2147942405: Access is denied.

So I went looking to make sure that the server was up, and our Administrator account had local machine rights, it was there.

After some further investigation I also found out that the SCCM site server also needs administrative rights, so I added the computer to the local administrator group and restarted the site component manager to force it to retry installing the components and the error disappeared and SCCM began installing the components onto our SQL Server.

Speeding up LAN based Automation OS boot times using a Custom TFTP Server for Altiris (for WinPE and Linux)

One of the more easier ways of speeding up your WinPE boot times via PXE are changing the default TFTP server which comes with Altiris. First of all, open up the PXE Configuration Manager and disable Multicast since the WinPE image cannot be transferred over Multicast anyway(only DOS supports Multicast via TFTP). This simple tweak shaves around a second off your PXE Boot time.

Another tweak which can be performed is changing the TFTP Server itself. This sounds quite difficult but is quite easy to accomplish and is a significant benefit.  My own testing has shown that 10 Clients concurrently loading a WinPE image do it around 45-50% faster using another TFTP Server than if I was to continue using Altiris’s own server.

I was also going to cover compressing the WinPE image to reduce its file size, but found thatwhen doing so, the reduction in size was minimal shaving off around 10mb.

I’ll be using the Open Source Open TFTP Server, available from http://sourceforge.net/projects/tftp-server/. Download it and install it either on your Altiris Server or like I did, on my workstation and then copy it over to your server. You will also need to copy over your Settings file.

Firstly, open up the Services control applet and Stop the Altiris PXE MTFTP Server service.

Now comes the good part. Open an elevated command prompt. The following is based on our Altiris setup, with it installed on D drive and me creating a folder under PXE for OpenTFTP and pasting the OpenTFTP executable and Settings file into that folder.

sc config "Altiris PXE MTFTP Server" binpath= "D:\Deployment Server\PXE\OpenTFTP\OpenTFTPServerMT.exe"

That will reconfigure the MTFTP service path that Altiris uses to push out files from the Altiris supplied MTFTP to our Open TFTP server. You can go into the Services control applet and start the Altiris MTFTP service to begin using the new executable.

To try and get the most out of OpenTFTP server, have a play with the Settings file, primarly the blksize option. Ours is set to 1456 and can be changed depending on your network environment.

If for any chance you want to return to the Altiris MTFTP server then you simply need to run the sc config command pointing to your Altiris PXE MTFTP executable so stop the service again and enter the following into an elevated command prompt making sure to match the path to your Altiris location:

sc config "Altiris PXE MTFTP Server" binpath= "D:\Deployment server\PXE\PxeMtftp.exe"

Then start the service again and you are back to using the default Altiris multi-thread TFTP server.

This simple tweak shaves heaps of time off of WinPE (also Linux) automation boot times. If you are running the Dos based automation then there isn’t really a need to run this tweak as the transfer is small enough not to take long anyway.

Hope that helps.

How to set (and change) an NTP time source in Windows Server 2008 R2 (SBS 2011 and Vanilla Server).

Recently, the clocks on my home networked PCs began drifting off sync until the difference was around 30 minutes. At first i thought that my SBS server was no longer synching with time.windows.com (the default time server for windows). After a quick look at the event log, I could see that it was syncing correctly and that the date and timezone were correct. So I began to look at how I could change the NTP server that Windows was syncing with. Unlike Windows XP, which had a tab were you could set the source and even add your own in the date and time control panel applet, Windows Server 2008 and Windows 7 have nothing of the sort, so how was I going to change the source. A quick look on technet led me to an article titled Windows Time Services Tools and Settings.

To query the time service about its current status open up an elevated command prompt and type in:
w32tm /query /status

This will display the following output (it will either state Source: Local CMOS Clock or time.windows.com)

After working out the souce and that it was synching without error as well as the obvious the fact the time was way off I needed to find a reliable Time service. After a bit of searching around the web I found pool.ntp.org which is the part of the home for the Network Time Protocol open source project (ntp.org). Members work together to provide a public pool of time servers for use by individuals and businesses. pool.ntp.org uses DNS round robin to make a random selection from a pool of time servers who have volunteered to be in the pool making this service highly redundant and reliable.

If you navigate to the Time Servers page on their wiki you will see a list of servers as rell as regional servers which you can also choose from.  Since I’m in Australia I narrowed it down to Oceanaia and then Australia leaving me with au.pool.ntp.org.  So basically I now had to reconfigure the Windows Time service to sync with the NTP Australian Server Pool. A quick look over the technet documentation told me the commands I needed to run which was:
w32tm /config /manualpeerlist:au.pool.ntp.org

Which after being executed in an elevated command prompt will leave you with command completed successfully.  Once that is configured we need to restart the time service by either doing net stop/start w32time or via the Services Control Panel on Windows Time.

You can then query the time service again using /query and /status which will present you with the above output. As you can see the time service is now synching with the service that I specified it to. You can look around the NTP site to find a group of services which are closer to your location, but it generally doesn’t matter where you pick the NTP server from.

And there you have it, how to reconfigure the Windows Time service to look at a different time source.  As a side note before closing off the article, Microsoft don’t fully support the Windows 32 Time service for use in high accuracy environments as mentioned in this Knowledge base article. So if you need something which is highly accurate then you need to look elsewhere.

How to Switch from IDE to AHCI without repairing/reinstalling Windows

A few weeks ago I installed an SSD drive in my home PC. For some reason up until tonight I never checked what the Sata mode was set to in the bios. It was set to IDE. Usually when changing the storage mode in the bios requires a reformat as windows will no longer boot. So I looked around the internet and found some really great instruction to switch from IDE to AHCI without having to repair or reinstall windows. Thought I might share it.

You start with step 1 while you are still in windows in IDE mode.

  1. Run the Registry Editor (regedit.exe)
  2. Navigate to Registry Key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Msahci
  3. Set the “Start” value to 0 (zero)
  4. Navigate to Registry Key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Pciide
  5. Set the “Start” value to 0 (zero)
  6. Shut down
  7. Start up again, but before Windows boots go into the BIOS configuration screens and change the disk mode to “AHCI”. Save the new BIOS configuration and restart so that Windows boots.

When Windows starts, it will detect the change, load new disk drivers, and do one more reboot to start up with them. A quick little post, more to come.

Changing the Registered User Details for Visual Studio 2010

One of the anoyances I’ve had when installing Visual Studio 2010 is the removal of the user information bit when accepting the License Agreement, this was useful but is now automated and the installer retrieves details from Windows itself.

After a fresh install of Windows 7 (with SP1 and it still needed updates afterwards) I installed my usual things along with Visual Studio, and thought now, how do I change the registered user details that show up in the about box, splash screen and are used as default values in the version resource. After having a quick poke around in the registry, I found the two areas that Visual Studio looks at. For a 64-bit machine they are the following two keys:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\10.0\Registration\UserName
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\RegisteredOrganization

For 32-bit machines:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\10.0\Registration\UserName
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\RegisteredOrganization

Changing these two will fix your about box, but what about that splash screen. Well running devenv.exe /setup with admin rights will cause Visual Studio to retrieve these registry settings and then make them appear in your splash screen. Making the circle complete which is what we set out todo. Hope that helps.

Fixing Error 1935. An error occurred during the installation of assembly errors.

Sometimes when installing software, I get an error during the installation of either the .Net framework or the Visual C Runtimes. This error, Error 1934. An error occurred during the instllation of assembly … will prevent the installation from being successfull, furthurmore after many hours of searching, many of the fixes listed around the web do not work.

To succsesfully allow the software installation to complete, a registry edit must be made. So go an open up Regedit and navigate to the following key: HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Control double-click on the RegistrySizeLimit and edit the DWORD value. In Hexadecimal enter FFFFFFFF or alternatively enter 4294967295 as the decimal value.

Once the registry change is done, restart the machine and then you can start the setup again that was causing you the issues earlier.

An optional set you can do once you have restarted the machine is to open up a command prompt window and type in the following command: SFC /SCANNOW this begins a windows file integrity checker ensuring that all windows system files are genuine and have not been edited or replaced, if you are running Windows XP you will need your installation CD to complete the scan.

Just about every encounter I’ve had with this error the RegistrySizeLimit has fixed the issue.

Exchange Management with AD Users when using RSAT for Windows 7

One of the little things with the have annoyed me since I’ve started using the RSAT tools in Windows is the fact that there is no easy way to manage Exchange. Sure I can install the Exchange Management Pack and use that, but like most admin’s AD Users and Computers is open just about all the time.

First thing you will want to do is go and download the Exchange System Manager for Windows Vista (located here). Once downloaded, extract the .exe file so that you have an ESMVISTA.MSI file. Now that’s extracted, open up a command prompt window and move to the location that ESMVISTA lives. Type in the following:

ESMVISTA.MSI /Q

With that command line the message is surpressed and the installation continues without any issues under Windows 7. This will only work for Windows 7 32-Bit and I have not found a way to get it working with 64-bit.

After a few minutes you will be able to open up AD Users and computers, right click and you will have the extra Exchange Tabs (pictured right), making Administration a little easier.

Office 2010 and Windows Sysprep Adventures

For our new roll out next year, we are deploying Microsoft Office 2010 and using KMS as our licensing method. Througthe use of sysprep’s generalize command, Windows will flush its Activation Status and associated hardware ID as well as rearming the activation state to its fresh install state (grace period).

With the introduction of Office 2010 brings improved piracy protection.  On our test deployment we found that our KMS Client count for Office 2010 wasn’t increasing and therefore wouldn’t reach the required count of 5 for activation, what was going on!  After a little bit of digging and the use of the Office 2010 Software Protection VB Script (ospp.vbs under the Office14 folder) we were able to see that the five of our test machines had the same CMID, therefore KMS thought that each was the same client. After a quick look through Technet we found out the issue.  When you run an Office Product it would automatically attempt to activate via KMS. Our Office installer also had its own activate upon installation command as well.

The fix for this issue and getting the count to increase (and finally activate) was to run a re-arm utility provided under program files (or program files x86, depending on your installed flavor):OSPP with DCMID

C:\Program Files\Common Files\Microsoft Shared\OfficeSoftwareProtectionPlatform\ospprearm.exe

Running the utility under an elevated command prompt will then show completed successfully. If you wish to double check you can then run ospp.vbs with the /dcmid switch and find that there is now no Client Machine ID.

Once this is compelte, run your sysprep as you would and you will find that for each client that you activate from now on for your KMS will increase your count.  You will also find that if you have some clients with the same ID then they will also all activate.

I plan on having some other articles covering articles regarding Windows 7 sysprep so stay tuned.

Remotely enable Remote Desktop to connect to a remote PC

Occasionally you need to get something done on a remote computer (or a clients computer) but the computer doesn’t have an easy way for you to connect to it. Luckily, if you have admin rights to the remote computer, you can still connect without needing to turn on remote desktop before hand. To do that you will just need to download a little tool called PsExec (Available here). PsExec is a Microsoft tool part of their PsTools, the beauty of it is that it is portable and can be run from anywhere.

Once you have PsExec download you just need to open a command prompt and browse to the folder with psexec.exe. Once the command prompt is open, type in this command and it will enable remote desktop on the machine you specify.

psexec \\machinename reg add “hklm\system\currentcontrolset\control\terminal server” /f /v fDenyTSConnections /t REG_DWORD /d 0

Make sure you replace “machinename” with the computer you are trying to control remotely. Once this command has run you should now be able to connect with the Remote Desktop client (mstsc.exe) to the remote computer.

Fix client machines not appearing in WSUS Console

Depending on your imaging method some clients may not show up on your WSUS console, and refuse to check for updates. Since starting my new job I’ve seen this occur on machines which have been imaged with a non-sysprepped image. I quickly whipped up a script to reset some settings and forcing the machine to contact your WSUS server and retrieve a new Client Id and thus show up in your console.

Dim objShell, strKeyPath, strValueName,strComputer

set objShell = wscript.createObject("wscript.shell")

const HKEY_LOCAL_MACHINE = &H80000002

strComputer = "."

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set objRegistry = GetObject("winmgmts:\\" & strComputer & "\root\default:StdRegProv")

strKeyPath = "SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate"
strValueName = "SUSClientIdReset"


objRegistry.GetStringValue HKEY_LOCAL_MACHINE, strKeyPath, strValueName, dwValue
IF (dwValue = "1") Then
            'do nothing
      Else
            objRegistry.DeleteValue HKEY_LOCAL_MACHINE,strKeyPath,"SusClientId"
            objRegistry.DeleteValue HKEY_LOCAL_MACHINE,strKeyPath,"SusClientIdValidation"

   Set colServiceList = objWMIService.ExecQuery ("Select * from Win32_Service where Name = 'wuauserv'")

   For Each objService in colServiceList
     If objService.State = "Running" Then
     objService.StopService()
     Wscript.Sleep 10000
     objService.StartService()
     End If
   Next
        objShell.Run("wuauclt /resetauthorization /detectnow ")
   	Wscript.Sleep 10000   
        objShell.Run("wuauclt /r /reportnow")

        'Set reg value for SUSClientIdReset for checking against later.
   	dwValue = "1"
        objRegistry.SetStringValue HKEY_LOCAL_MACHINE, strKeyPath, strValueName, dwValue
End If

Run that on the effected machine with Admin Rights and the client will eventually appear in your WSUS Console.

As for the cause, the master image was joined to the domain and tested. During that time received group policy settings which included WSUS and contacted the server settings it’s clientId.

Hope that helps.