Monthly Archives: August 2014

WSUS Log Files

So often when interviewing or working with colleagues I often hear the question:

‘What is the best log file to look in if Updates are not deploying via ConfigMgr to clients????’

Well the answer is there is not just one. A number of log files work together to reflect the process of updates deploying and a few key ones I use are below:

Wsyncmgr.log
WUAHandler.log
Wsusctrl.log
WCM.log

Along with

Datatransfer.log
CAS.log

Often the issue will lie somewhere within these logs if the issues is specific to update deployment.

There is still the standard windowsupdate.log but I find the above are more granular where the issue lies if a problem was to occur!

Windows Server 2012 – Switch between Core and GUI

Now in Windows Server 2012 there is no longer a one time decision to be made when you perform the installation of which GUI type you wish to imprint on the server.

This can be changed in using DISM with the following command.

Dism /online /enable-feature /featurename:ServerCore-FullServer /featurename:Server-Gui-Shell /featurename:Server-Gui-Mgmt

Microsoft SQL Servername does not match computer name

Anyone who has downloaded any of the Microsoft Hydration kits of late looking to import them into their own lab especially in my case as SQL 2008 is becoming harder and harder to get hold of nowadays may of stumbled over just what I did today.

By renaming the machine and joining to my lab domain generated a warning in OpsMgr pre-req as machine name was different to when SQL was installed.

Quickly resolved in management studio by the following:

 

Confirm current name – select @@ServerName

 

Then execute the following statements.

Run Query from the SQL query window one statement at a time

sp_dropserver ‘old_server_name’
sp_addserver ‘new_server_name’, ‘local’

My Server required a reboot to pick up the changes!

Report Server DB SQL Server Error Log 9002 – ConfigMgr 2012

Working at a client site this week after retuning for a health check I noticed that the SQL Server Log drive for SRS had consumed almost all of the disk available at 30GB!!!

Now as we know the logs for SRS should not be anywhere near that and trying to shrink down the available space proved fruitless as SQL was complaining about the disk being full. The auto grow was configured to consume all disk so this could not be amended easily.

As an Interim measure the recovery model on the database was set to Full which once changed to Simple allowed the database shrink to be implemented and corrected thus preventing SQL from consuming all of the disk.

Now the auto grow can be amended and if required recovery model reverted back to full.