Wednesday, March 24, 2010

WMI Repair Command:- For Windows 2008 and Windows Vista/7

For For Windows 2008 and Windows Vista/7

winmgmt  /salvagerepository


For Windows Server 2003

rundll32 wbemupgd, RepairWMISetup

  • cd /d %windir%\system32\wbem
  • for %i in (*.dll) do RegSvr32 -s %i
  • for %i in (*.exe) do %i /RegServer
Note that none of the above two methods restore the missing files related to Windows Management Instrumentation (WMI). So, below is a comprehensive repair procedure that restores all the missing WMI modules. In case of missing WMI modules, you may use the following method.




Comprehensive rebuild method

Important note:  If you've installed a Service Pack, you need to insert your Windows XP CD with Service Pack integration (called as the Slipstreamed Windows XP CD). If you don't have one, you may point to the %Windir%\ServicePackFiles\i386 folder for a recent version of the system files required during WMI repair. Or you may create a slipstreamed Windows XP CD and insert it when prompted.

Click Start, Run and type the following command, and press ENTER:

rundll32.exe setupapi,InstallHinfSection WBEM 132 %windir%\inf\wbemoc.inf

Insert your Windows XP CD into the drive when prompted. Repair process should take few minutes to complete. Then restart Windows for the changes to take effect.



For XP/2k3/2000


1. Open a CMD prompt on the server and change directory to %windir%\System32\WBEM (\SysWOW64\WBEM on x64)

2. Execute the following:

FOR /f %s in ('dir /b /s *.dll') do regsvr32 /s %s
Net stop /y winmgmt
FOR /f %s in ('dir /b *.mof *.mfl') do mofcomp %s
Net start winmgmt

Note: Don't attempt to compile the MOF files in the \bin\i386 folder on a site server, as we contain stub files (names start with an underscore character such as _smsprov.mof) that need to be populated with site specific data through other means.   


SCCM in Multi Forest design

Full information available for multiple forest is here

Top Rapidshare Search Engines


• -





Tuesday, March 23, 2010

Where Name0 in

Deleting Machines Directly From The SMS Database

To delete an individual machine from the SMS database using the SMS console it is necessary to create a collection using the direct membership rule wizard or base your new collection on a newly created Query. The first method is slow and can be time consuming, the second option just doubles your work and it the least desired method for most people.

The other automatic means in which you can remove or otherwise delete the machine(s) from the SMS database is to let the SMS_SQL_MONITOR service automatically remove the machine after it has reached its predefined Site maintenance task ‘Delete Aged Discovery Data’ and ‘Delete Aged Inventory History ‘ specifications if you have left it enabled. It is enabled by default and is set to 90 days. You can however change this to a more reasonable time period appropriate for your sites hierarchy if needed.

Below you will find a SQL query that will allow you to delete machines from the SMS database as the task “Delete Special” performs the removal process. It is important to note here that when you delete machines from a collection within the SMS console the machine is deleted from the database however the History table is not purged or removed. When you use the task Delete Special the machine is not only removed from the SMS database but the history for the machine is also deleted.

NOTE: You must uninstall the SMS client software to ensure that it does not report back in. If you are simply removing the machine name(s) from the SMS database because your site support staff has informed you that the machines were retired or re-imaged then this is not necessary. It is important to also note here that this is not a Microsoft supported means for deleting machines from the SMS database and should be used in a non production environment.

When you are done use the query in my earlier post entitled: ‘Searching Your SQL Database For A Specified Column String’ and search for the machine(s) that you just deleted to ensure that they have in fact been purged.

To delete multiple machines using the query that follows you can simply change the line that reads: Where Name0 = 'Machine_Name' To the following: Where Name0 in ('Machine_One', 'Machine_Two') as in the Deleting Multiple Machines SQL Query found at the end of this post.

  • Deleting An Individual Machine SQL Query:

Insert DeletedMachines (SmsId)

Select IsNull(Sms_Unique_Identifier0,'')

From System_Disc

Where Name0 = 'Machine_Name'

And Sms_Unique_Identifier0 is not null

Delete System_Disc from System_Disc

Where Name0 = 'Machine_Name'

Delete System_Data from System_Data

Where Name0 = 'Machine_Name'

  • Deleting Multiple Machines SQL Query:

Insert DeletedMachines (SmsId)

Select IsNull(Sms_Unique_Identifier0,'')

From System_Disc

Where Name0 in ('Machine_One', 'Machine_Two')

And Sms_Unique_Identifier0 is not null

Delete System_Disc from System_Disc

Where Name0 in ('Machine_One', 'Machine_Two')

Delete System_Data from System_Data

Where Name0 in ('Machine_One', 'Machine_Two')

Group Policy Software Deployment: Targeting the right computers with WMI filters

Group policy was introduced with Windows 2000, and is an easy way of centralizing many Windows settings. In addition to centralizing event log and firewall settings, I personally like the ability to deploy MSI-based software applications with Group Policy, since it makes it extremely easy to deploy new software packages.
Even though Software Installation only works only with MSI-based packages, it does make deploying MSI-based software packages extremely easy.  

We generally deploy software through Group Policy when three or more computers use it, since it's very easy to create a new package (if you already have a network share etc. setup, then you can literally do it in 2 minutes).

Before I list some of the useful WMI queries we use to target certain operating systems or computer types, there are a couple of things to note for those who are new to software deployment via group policy:

  • Software packages are always installed right after a reboot, so they're mostly suitable for workstations.
  • The network share which hosts the MSI files needs to give the computer accounts (e.g. DESKTOP1$) at least read access. Generally, giving EveryOne Read access works well unless you have a reason to restrict access to the software packages that you distribute.
Since the mechanism to distribute software is based on group policies, any sort of software package you create inside a group policy, will need to be assigned to an organizational unit (OU).
Since OUs can contain a large amount of computers that might not all need that particular software package, you can use two techniques to narrow down which computers receive the software:
  1. Security Filtering
  2. WMI Filtering
Security Filtering
With this method, you create a security group in Active Directory, place the computers that should get a particular software package into the group, and then specify this group in the Security Filtering list.
The screen shot below shows a group policy that will only be applied to members of the "Source Control Computers" group:image

WMI Filtering
With this method, you can filter the computers which are affected by your policy, based on common properties of the Operating System. For example, some packages might distinguish between 32-bit and 64-bit, some packages might only work on Vista or later, whereas other packages apply only to servers. With WMI, you can target the right computers without having to mess with group memberships (though you will probably still need to do that). For example:

  • 32-bit vs. 64-bit computers
  • only workstations
  • only computers running a certain OS
  • only computers with a certain amount of RAM
  • only computers of a certain brand
With WMI filtering, you just create the software group policy, for example:
  • 7-Zip 32-bit
  • 7-Zip 64-bit

and then apply the respective WMI filter to them. But lets cut to the chase, here are a few WMI queries that you can cut & paste:
Operating System 32-bit
Select * from Win32_Processor where AddressWidth = '32'
Operating System 64-bit
Select * from Win32_Processor where AddressWidth = '64'

Select * from WIN32_OperatingSystem where ProductType=1
Domain Controller
Select * from WIN32_OperatingSystem where ProductType=2
Select * from WIN32_OperatingSystem where ProductType=3
Some filters require multiple WMI queries, which are just chained together.
Workstation 32-bit
Select * from WIN32_OperatingSystem where ProductType=1
Select * from Win32_Processor where AddressWidth = '32'
Workstation 64-bit
Select * from WIN32_OperatingSystem where ProductType=1
Select * from Win32_Processor where AddressWidth = '64'


Windows XP
Select * from WIN32_OperatingSystem where Version='5.1.2600' and ProductType=1
Windows Vista
Select * from WIN32_OperatingSystem where Version='6.0.6002' and ProductType=1
Windows 7
Select * from WIN32_OperatingSystem where Version='6.1.7600' and ProductType=1
Windows 2003
Select * from WIN32_OperatingSystem where Version='5.2.3790' and ProductType>1
Windows 2008
Select * from WIN32_OperatingSystem where Version='6.0.6002' and ProductType>1
Windows 2008 R2
Select * from WIN32_OperatingSystem where Version='6.1.7600' and ProductType>1
WIN32_OperatingSystem of course includes more information that can be useful for WMI queries, such as a descriptive name of the installed OS ("Name") as well as the service pack installed ("ServicePackMajorVersion").
Manufacturer (e.g. DELL)
Select * from WIN32_ComputerSystem where Manufacturer = 'DELL'
Installed Memory (e.g. more than 1Gb)
Select * from WIN32_ComputerSystem where TotalPhysicalMemory >= 1073741824

For more information, check out these resources on WMI:
Secrets of Windows Management Instrumentation
Scriptomatic (Vista/Win2k8/Win7: run as administrator!)

Monday, March 22, 2010

Reset done by any user for Site Status (SMS_COMPONENT_STATUS_SUMMARIZER)

If any user done Site reset if found in red/yellow to set to OK… then below message will appear



also you will see below information in one of other message

“SMS Site Control Manager added a "Property List" item named "Reset SMS_COMPONENT_STATUS_SUMMARIZER:1269225968" to the actual site control file D:\apps\sccm\inboxes\\sitectrl.ct0.

This addition occurred as a result of a site configuration change request in delta site control file D:\apps\sccm\inboxes\\incoming\t1wv43np.CT1. The change will take effect in serial number 84 of the actual site control file.”



Hope this helps to find who has reset the SMS / SCCM Site

Remote Server Administration Tools RSAT

Remote Server Administration Tools(RSAT)

Download Location:-


VPN Reconnect

Offline Domain Join


New Group Policy capabilities


Domain Name System Security Extensions (DNSSEC)

Windows Deployment Services supports Windows 7 deployments

What is Disaster? DR?

An event, usually a major or catastrophic that denies access to the normal facility of business (or technology processing) for an extended period that would require relocation to an alternate site or sites.

Sunday, March 21, 2010

Batteries recommended

SEMI - TUBULAR Batteries - These are Modified Versions of Automotive Batteries and are Designed for Inverter Applications .. They come with 18 Months Replacement Warranty + Some Rebate for the Next 6 months if battery Fails and Average Life of these Batteries is 3 years..These Batteries Need Topping of Distilled Water once in 3 4 Months .

Models  Recommended  by us :- EXIDE INVERTER + Series /  SF POWERBOX Series. ( 18 Months Replacement + next 6 Months 50% Rebate )

TUBULAR Batteries :-  These are the Batteries which are Specially Designed for Inverters , UPS & Telecom Purpose where Continuos Current is Required at the Time of Power Failure .. The Plates in the Batteries are Very Thick which gives you Excellent Power Back up and Life .. They Usually come with 2 Yrs & 3 Yrs Replacement Warranty and average Life of these Batteries is 5 -7 Years..there is no smell or fumes from these batteries and maintainance is required only once in 6-8 months