Tuesday, November 20, 2012

SCSM 2012 Data Warehouse Cube Processing Keep Failing


I personally find it very annoying when you imported a management pack (MP) in your SCSM and the next day all Cube Processing job failed without reason.

Have been seeking high and low for fix this and finally with combine article from Technet and forums by hundreds miserable user same as myself, the cube processing can be fixed using below method

Firstly lets Disable Data Warehouse Cube Processing jobs via Power Shell (make sure to change to correct Program Files install directory for SCSM):

Import-Module '%ProgramFiles% \Microsoft System Center 2012\ServiceManager\Microsoft.EnterpriseManagement.Warehouse.Cmdlets.psd1'
Disable-SCDWJob "Process.SystemCenterConfigItemCube"
Disable-SCDWJob "Process.SystemCenterWorkItemsCube"
Disable-SCDWJob "ProGetcess.SystemCenterChangeAndActivityManagementCube"
Disable-SCDWJob "Process.SystemCenterServiceCatalogCube"
Disable-SCDWJob "Process.SystemCenterPowerManagementCube"
Disable-SCDWJob "Process.SystemCenterSoftwareUpdateCube"

Login to the server hosting the Analysis service and run the powershell script, just remember to change the$Server.Connect and the $DWASDB with the correct server (being the name of the SQL Server) and database name. It usually runs for 5-15 minutes. In my case, it took me about 45 minutes, so not to worry if the Powershell hung. When complete, you can verify by looking at the properties at one of the dimensions


[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.AnalysisServices")
$Server = New-Object Microsoft.AnalysisServices.Server
$Server.Connect("serverdw.blog.com")
$Databases = $Server.Databases
$DWASDB = $Databases["DWASDataBase"]
$Dimensions = New-Object Microsoft.AnalysisServices.Dimension
$Dimensions = $DWASDB.Dimensions
foreach ($Dimension in $Dimensions){$Dimension.Process("ProcessFull")}



Now you have to enable back all the cube processing job you have disabled earlier.

Enable-SCDWJob "Process.SystemCenterConfigItemCube"
Enable-SCDWJob "Process.SystemCenterWorkItemsCube"
Enable-SCDWJob "ProGetcess.SystemCenterChangeAndActivityManagementCube"
Enable-SCDWJob "Process.SystemCenterServiceCatalogCube"
Enable-SCDWJob "Process.SystemCenterPowerManagementCube"
Enable-SCDWJob "Process.SystemCenterSoftwareUpdateCube"

The final step to do is to process all the cubes


Notice that the cube processing finish without error.

hope this help out all other out there with SCSM 2012 Cube Processing issue.


Thursday, October 25, 2012

Hyper-V 2012 : VLAN Trunking

During one of our Microsoft Hyper-V 2012 deployment (without GUI) on HP 160 G5, we have come across a very interesting finding of the built-in capabilities where you can now TRUNK VLAN without HP Network Configuration Utility (HPCU)

It was both the shock an excitement that night when both myself and Hafiz found that by adding a DWORD to the registry and a clean restart... VOILA ! the VLAN trunking works as expected.

This is the location to find for the registry key that you have to add.


HKEY_LOCAL_MACHINE\ControlSet001\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}\00xx

xx could be any number so you must open each key and look for your network adapter. If you are using NIC Teaming you probably need to do this for both adapters or all adapters that set up your team, in case you have more than two.




So, what is so great about this ?

Remember back in Windows Server 2008 R2 SP1, you need to install HPCU (Not an option). After the installation, you have to use HPCU to create VLAN(802.1q) with the NIC port of you choice. 

And the next complication was that for each VLAN that you trunk, there will be additional Network Adapter create for that particular VLAN

Imaging you have 2 NIC ports and you have 5 VLANs that you need to trunk them for the VMs. This will gives you 10 extra Network Adapters show in Network Connections window. MESSY !!!

Now that we can do this without HPCU, you only need to specify the VLAN in the Virtual Network of the VM that want to connect to.

Tuesday, October 23, 2012

SCSM 2012 : Work Item Running Number


One counter for all types of work items:
For instance:

  • New Incident = IR1
  • New Change Request = CR2
  • Change Request contains 2 activities = RA3 and MA4
  • New Incident = IR5

and so on

All work items are sharing the same counter for ID. Only the prefix is added to this ID based on the work item class (IR, CR, PR, SR, MA, RA).
For this reason the ID is not increment uniformly for each type of work item.
This behavior can't be changed. 

However, you can set the starting number by changing a value in the database.

Basically there is this table in the ServiceManager database called the AutoIncrementAvailableRange table.  This value stores the next available number for a particular class property.  If the last work item ID that was handed out was 1234 this table would show 1235 and then once 1235 was used it would say 1236.  You get the idea.  So, by changing this number we can change the base number that we start from.  Let’s say for example that we always want our incident IDs to be in the 10,000+ range.  We could change thus number to 10000 and start from there.  Definitely don’t set it lower than the current number though!  That will most likely be very bad.

Use the SQL command below to set the new number you want
update AutoIncrementAvailableRange
set FirstAvailableValue = 10000 
where ManagedTypeId = 'F59821E2-0364-ED2C-19E3-752EFBB1ECE9' and ManagedTypePropertyId = '28B1C58F-AEFA-A449-7496-4805186BD94F'
Use the command below to check if the value changed to the one you set using command above
select
MT.TypeName,
MT.ManagedTypeId,
MTP.ManagedTypePropertyName,
MTP.ManagedTypePropertyID,
AIAR.FirstAvailableValue
from ManagedType as MT, ManagedTypeProperty as MTP, AutoIncrementAvailableRange as AIAR 
where MT.ManagedTypeId = AIAR.ManagedTypeId and MTP.ManagedTypePropertyId = AIAR.ManagedTypePropertyId
Notice that at the end of the role "System.WorkItem", at the "FirstAvailableValue" column, the number is the number you have set.