Bypass Corporate WSUS for update check

I've had an issue a couple of times now when testing/running Windows 8 in an environment where group policy enforces WSUS settings causing a problem as the WSUS server hasn't been updated to support Windows 8 clients or hasn't had the required updates published.

Sometimes this can easily be got around by simply clicking the "Check online for updates from Windows Update" link, however this was removed by GPO in these cases.

In these cases I've had to fall back to using this simple batch file script:

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v UseWUServer /t REG_DWORD /d 0 /f
net stop "Windows Update"
net start "Windows Update"
control /name Microsoft.WindowsUpdate

After running this batch file, you can run Windows Update as normal and it will go directly to Windows Updates to check.

This is obviously not something a normal "user" should use, but then they shouldn't have the access rights to run this anyway!  Neither is it a permanent workaround, just a quick fix while the WSUS server is updated to provide Windows 8 updates.

Previous blog post on preparing WSUS for Windows 8/Server 2012:
http://systemscentre.blogspot.co.uk/2012/09/preparing-wsus-for-windows-8-and-server.html

Error when creating MDT Packages for ConfigMgr 2012

Recently I ran into an error while creating the MDT 2012 packages for use with ConfigMgr, unfortunately the error message was not the most useful one to be seen...

Ok, so access to the path is denied... but what's the path that it's trying to access???


This occurs when stepping though creating a new MDT task sequence and selecting to create new packages for the first time and unfortunately you have to re-step though all of the wizard options from scratch each time while trying to troubleshoot.

Anyway, long story short, running Process Monitor while trying to create the packages showed it failing while trying to create an autorun.inf as part of the MDT Package.

 

While the screen shot above shows a successfully built package, the folder we were seeing contained a temp file only.

 

A bit more digging narrowed it down to McAfee Anti-Virus running on the server that was blocking the creation of Autorun.inf files.  Strangely enough though it didn't block the MDT installer or the creating of the deployment share.

 

After messing with disabling the AV and stopping services to prevent the ePO restarting the AV we ran through the MDT Task Sequence wizard again and it installed successfully.

 

 



I suppose I should have paid more attention to the note by Michael Niehaus on this old blog post for MDT 2010 Update 1

VMM 2012 SP1 (Beta) with Server 2012 Hyper-V Issue

After migrating my 2008 R2 cluster across to Server 2012 I was having problems adding in the cluster/hosts to SC2012 Virtual Machine Manager SP1.

The cluster could be discovered and imported fine, but a few minutes later would report back that it could no longer be managed.

It turns out that because on the rebuild I didn't make the hosts DC's (it's a testlab before someone comments on best practise!!) so the computer accounts got placed into an OU along with the normal servers that had a Group Policy applying some WinRM settings.
Unfortunately doing a winrm /qc or allowing VMM to check that WinRM is enabled doesn't set/check all the required settings are actually in place.

Having a look around I found the following TechNet forum post from Wes Kroesbergen who listed a registry key that's advisable to have set, plus the winrm commands to set all of the required settings.

http://social.technet.microsoft.com/Forums/en-US/virtualmachingmgrhyperv/thread/4bd9be4b-0ff9-46f3-bf32-1b7c1245c494


Wrap the below into a batch file (you can't use these commands via PowerShell before you try), run it on your Hyper-V hosts and you're good to go!

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

winrm set winrm/config/service/auth @{CredSSP='True'}
winrm set winrm/config/winrs @{AllowRemoteShellAccess='True'}
winrm set winrm/config/winrs @{MaxMemoryPerShellMB='2048'}
winrm set winrm/config/client @{TrustedHosts='*'}
winrm set winrm/config/client/auth @{CredSSP='True'}

SCVMM 2012 SP1 - Missing properties and unable to refresh VM

Giddy as a kid in a sweet shop I migrated my testlab cluster to Server 2012, migrated my VM's across and installed System Center 2012 Virtual Machine Manager SP1 to manage it.

Straight away I ran into some slightly strange issues.

1. Majority of the Auto Discovered VM's refused to see hardware configuration properties such as:
   Virtual Hard Disks and Controllers
   Virtual Network Cards
2. Majority of the Auto Discovered VM's left hardware configuration properties at defaults, such as:
   Processor Count and Memory Amount
   High Availability Status
3. Every time I tried to refresh a VM I would get the error:
   Error (2923)
   
   A malformed response was received while trying to contact the VMM agent on hyperv01.domain.local.
   Unspecified error (0x80004005)
   
   Recommended Action
   1) Ensure the VMM agent is installed and that the SCVMMAgent service is running.
   2) If the SCVMMAgent service is running, restart the service, and then verify that WS-Management is installed correctly and that the WinRM service is running.
   3) Check the manufacturers' Web sites to ensure that you have the latest drivers for your network adapters and other devices.

Looking on the Microsoft Connect site I found that someone called egilsk was having the same issues.

Thankfully, last Friday (05/10/12) Mark at Microsoft posted the following suggestion to try:

On the Hyper-V hosts run the following PowerShell commands

Import-Module Hyper-V

Get-WmiObject –Namespace “root\virtualization\v2” Msvm_PlannedComputerSystem | foreach{Get-VM –Id $_.Name} | Remove-VM –Force

Once this has been run on your hosts, refreshing the VM's should work successfully and all of the missing/default hardware config should be updated and displayed.

It looks like this is to do with the hosts having the VM stuck in a temporary state, even if brought across as a planned import or migration.

The problem is now at least known about and should be fixed/handled in the next release of the Service Pack.

SCOM Data Access Service Fails to Start

I was speaking to an old colleague the other day who is in the middle of migrating his production Operations Manager 2007 R2 environment to a nice new shiny 2012 setup.

Things were initially going well but he explained that he ran into a rather strange issue just after migrating the first batch of agents across to just talk to his live 2012 infrastructure, what made it stranger was these had been talking to his test infrastructure (dual homed) fine for quite a while.

When he moved them across, shortly after, the System Center Data Access service stopped and refused to start.

No matter what he tried it wouldn't work and he had to fall back to restoring a backup.

This left him a little hesitant about the stability of his live environment and whether something wasn't quite right underneath it all somewhere, but it seemed to be fine after the restore so he thought he'd see how it went.

Well the same problem reared it's ugly head again the other day so he did some more digging.

Eventually he stumbled across this post from Travis Wright explaining an issue seen in Service Manager.
http://blogs.technet.com/b/servicemanager/archive/2011/10/04/system-center-data-access-service-start-up-failure-due-to-sql-configuration-change.aspx

Since Service Manager and Operations Manager share the same code base and the problem described is essentially a SQL problem anyway he took a look to see if it was indeed the same issue affecting him, turns out it was!

It finally turned out to be something one of the developers were doing with custom reports and scheduling that was adding a local SQL account to the security roles as DBOwner (Dev to be taken outside and shot...)

So in summary, if you're using SCOM and your System Center Data Access Service refuses to start and you're seeing event log errors such as:

• 26325 Authorization store exception
• 26339 Exception thrown while initializing the service container
• 26380 Unhandled Exception

then take a look at the Service Manager blog link above and check your SQL security logins to see if something/someone is flipping the Authentication mode to Mixed-Mode.

Good find Rob, now get your blog back online and start sharing things like this again ;)

Duplicate Records when you use Unknown Computer Support along with AD Delta Discovery

I've run into this scenario a couple of times after enabling Delta Discovery and have got into the habit of doing a manual sweep for duplicate records, or extending the Delta Discovery period, but that kind of defeats much of the reason for it.

http://blogs.technet.com/b/configmgrteam/archive/2011/08/17/known-issue-and-workaround-duplicate-records-when-you-use-unknown-computer-support-with-active-directory-delta-discovery.aspx

Basically, if you have Delta Discovery enabled and then image a new device using unknown computer support SCCM creates a record for the new device, but then if Delta Discovery runs before the Task Sequence installs the Client Agent and after the OS has been joined to the domain, 2 records will be created within SCCM.  The problems start though when SCCM can't link/merge the two together and won't age either of the out of the database either.

Two choices are then left for you.

1. Manually sweep for duplicate records and delete the one that shows no client installed.


2. Setup a status filter rule that will run a script to automatically delete the record.

Thanks to the TechNet article posted by Minfang Lv, this is now relatively simple to do, with the scripts and instructions supplied.

As always, test before putting straight into production.

Troubleshooting the Service Manager Data Warehouse

Really useful blog post on the SCSM Engineering Team's blog:
http://blogs.msdn.com/b/scplat/archive/2010/06/07/troubleshooting-the-data-warehouse-an-overview.aspx

SMS_Distribution_Manager Component spammed with 2300 & 2301 messages

I had a strange problem with my secondary site the other day that I thought I'd share the fix for.

For some reason the SMS_Distribution_Manager component status message log was showing message ID's 2300 & 2301 every minute for a task sequence located on my Central site.

04/08/2010 21:06:16 SystemName SMS_Distribution_Manager 2301 SMS Distribution Manager successfully processed package "Corporate Image 32-Bit - Generic" (package ID = SC1001BA).
04/08/2010 21:06:16 SystemName SMS_Distribution_Manager 2300 SMS Distribution Manager is beginning to process package "Corporate Image 32-Bit - Generic" (package ID = SC1001BA).
04/08/2010 21:05:11 SystemName SMS_Distribution_Manager 2301 SMS Distribution Manager successfully processed package "Corporate Image 32-Bit - Generic" (package ID = SC1001BA).
04/08/2010 21:05:11 SystemName SMS_Distribution_Manager 2300 SMS Distribution Manager is beginning to process package "Corporate Image 32-Bit - Generic" (package ID = SC1001BA).
04/08/2010 21:04:06 SystemName SMS_Distribution_Manager 2301 SMS Distribution Manager successfully processed package "Corporate Image 32-Bit - Generic" (package ID = SC1001BA).
04/08/2010 21:04:06 SystemName SMS_Distribution_Manager 2300 SMS Distribution Manager is beginning to process package "Corporate Image 32-Bit - Generic" (package ID = SC1001BA).

Checking the Distmgr.log you can see the tasksequence re-trying every minute, but what's more interesting is that it explains it can't because a referenced package wasn't available.

Failed to insert SMS Program ID 49479 because the referenced program SC1001ED-* is not present in the PkgPrograms table. Will try later.

This turned out to be a driver package that wasn't distriuted to the secondary site.
OK, not a problem I thought, lets add it.

Hmm... that's not right.
Failed to insert SMS Package SC1001ED because SDM Type Content C727B3AC-0B5B-49D7-AA28-C8C6F3907E3A is not present in the CI_Contents table. Will try later.

Looking around, Jannes Alink had a similar problem last month:
http://social.technet.microsoft.com/Forums/en-US/configmgrgeneral/thread/1bd6908c-3395-4a39-a174-747b741927d4

I ran preinst.exe /syncchild and since it had so much to replicate through I left it to it.

Checking this morning however and the last (and final) retry of distributing the task sequence was at 23:54 the previous night, only 6 hours after doing a syncchild!

Problem solved.