SCCM admins get it all the time, they offer received request on either software or hardware inventory, what if for some reason, they just need a list of software that are installed in the client machine (less than five of them) for comparison sake, and it needs to be in CSV format?
Well, you could do that in SCCM reporting. But if you don't have time to look through over 200 report templates for an answer, you could use the below PowerShell command to list out the software name and version that will be exported into a CSV format, the file name will be the host name that you are running Powershell on so that you know which list does it belongs to.
Get-WmiObject -Class Win32_Product | Select-Object name,version |sort-object name | Export-Csv -Path "C:\$env:computername.csv"
Here are some of the little scripts that I have used along to work to get the administration work done. (So far)
1) Clear CCMCache using PowerShell
2) Use batch file command to check OS architecture for software deployment
Have fun!
SY
Tuesday 30 June 2015
Wednesday 24 June 2015
SCCM 2016 Technical Preview
It was announced a month back, however I didn't have the time to try out until now. If you haven't know already, ConfigManager Vnext or ConfigManager 2016 is out for technical preview.
You could download from MS evaluation centre (you need to register for the 60 days trial version):
https://www.microsoft.com/en-us/evalcenter/evaluate-system-center-configuration-manager-and-endpoint-protection-technical-preview
And Technet document over here:
https://technet.microsoft.com/library/dn965439.aspx
Basically for the setup I have used Windows Server 2012 R2 and SQL 2014 together. Standard installation steps apply. Turn out there was a new feature which I have discovered (Basically all the entire look and feel did not changed much):
Which I believe this OS upgrade option is inline with Windows 10 rollout. You can find out more about Windows 10 upgrade deep dive:
https://channel9.msdn.com/Events/Ignite/2015/BRK3307
At the point of writing it still in technical preview phase and nothing is carved in the stone yet. Let us wait for the next version of Config Manager.
Till then. :)
SY
You could download from MS evaluation centre (you need to register for the 60 days trial version):
https://www.microsoft.com/en-us/evalcenter/evaluate-system-center-configuration-manager-and-endpoint-protection-technical-preview
And Technet document over here:
https://technet.microsoft.com/library/dn965439.aspx
Basically for the setup I have used Windows Server 2012 R2 and SQL 2014 together. Standard installation steps apply. Turn out there was a new feature which I have discovered (Basically all the entire look and feel did not changed much):
Which I believe this OS upgrade option is inline with Windows 10 rollout. You can find out more about Windows 10 upgrade deep dive:
https://channel9.msdn.com/Events/Ignite/2015/BRK3307
At the point of writing it still in technical preview phase and nothing is carved in the stone yet. Let us wait for the next version of Config Manager.
Till then. :)
SY
Friday 19 June 2015
SCCM 2012 R2 Collection Design
This post was actually inspired by this thread how often do we actually think of designing a series of collection to help us to group the devices functionally and at the same time not sacrificing the SQL performance?
I have spend a lot of time gathering information and to my pleasant surprise it is a very big subject by itself, from Collection to the performance of SQL is closely knitted.
First what is collection?
From technet:
"Provide you with the means to organize resources into manageable units, which then enable you to create an organized structure that logically represents the kinds of tasks that you want to perform. "
Second, after we learn how the collection is related to SQL, in order to take care of the performance, the collection should refrain from complex queries as it will with temporary stored procedures, table variables or cursors. This is especially more true if your collection is too complex: https://msdn.microsoft.com/en-us/library/ms190768.aspx
Third, since tempdb is important and we cannot ignore this, you really want to setup your SCCM server or any other related products that uses MS SQL with at least four databases. From this KB:
https://support.microsoft.com/en-us/kb/2154845
Initial setup of 4 tempdb will be a good start off point. And because of heavy I/O involved it will be a good idea to place the tempdb in a separate hard disk, if you cannot afford to do that, monitor the size of tempdb and manage from there, give the initial size of the tempdb last than half of the CM database size.
Assuming the CM database is 100GB,
40GB (40% of 100GB) / 4 tempdb = 10GB each.
A nice article on tempdb initial sizing: http://logicalread.solarwinds.com/sql-server-tempdb-best-practices-initial-sizing-w01/#.VYQzIPmqpBc
My personal preference is to let the tempdb to grow in MB instead of percentage. To grow in MB helps you to capped it at a controlled fashion. To grow by 10% of 20GB is equal to 2GB vs To grow by 500MB at a time.
Fourth, how can we build a better collection query then? A general rule of thumb, a good collection query should avoid:
I hope this article have help you to understand your SCCM collection better. :)
SY
I have spend a lot of time gathering information and to my pleasant surprise it is a very big subject by itself, from Collection to the performance of SQL is closely knitted.
First what is collection?
From technet:
"Provide you with the means to organize resources into manageable units, which then enable you to create an organized structure that logically represents the kinds of tasks that you want to perform. "
 |
| So how is collection closely related to SQL? Collection creation is done using WQL, WQL is a subset of SQL and is mainly used in SMS provider to view device WMI details. |
 |
| In SQL, you are unable to execute WQL, all the WQL queries are kept in: Collection_Rules_SQL views, in here you can see that the WQL statements in the collection is converted into SQL statement. |
Second, after we learn how the collection is related to SQL, in order to take care of the performance, the collection should refrain from complex queries as it will with temporary stored procedures, table variables or cursors. This is especially more true if your collection is too complex: https://msdn.microsoft.com/en-us/library/ms190768.aspx
Third, since tempdb is important and we cannot ignore this, you really want to setup your SCCM server or any other related products that uses MS SQL with at least four databases. From this KB:
https://support.microsoft.com/en-us/kb/2154845
Initial setup of 4 tempdb will be a good start off point. And because of heavy I/O involved it will be a good idea to place the tempdb in a separate hard disk, if you cannot afford to do that, monitor the size of tempdb and manage from there, give the initial size of the tempdb last than half of the CM database size.
Assuming the CM database is 100GB,
40GB (40% of 100GB) / 4 tempdb = 10GB each.
A nice article on tempdb initial sizing: http://logicalread.solarwinds.com/sql-server-tempdb-best-practices-initial-sizing-w01/#.VYQzIPmqpBc
My personal preference is to let the tempdb to grow in MB instead of percentage. To grow in MB helps you to capped it at a controlled fashion. To grow by 10% of 20GB is equal to 2GB vs To grow by 500MB at a time.
Fourth, how can we build a better collection query then? A general rule of thumb, a good collection query should avoid:
- Using too much joints
- Refrain from using too
much "where" clauses
- Refrain from using "Like" and "Not Like" statements as it is consider a "expensive" in terms of SQL performance. As it causes table scans. https://msdn.microsoft.com/en-in/library/ff647793.aspx
Finally, considering all the above, you should consider the design of the Collection,
although there no hard and fast rule in the design, a good collection
design will not impact the SQL performance and to start off with a good
design you should consider:
- Collection naming convention should be direct and easy
to understand. You could either create the collection base on department
basis or by application basis.
- Refrain yourself using limiting collection especially
the root collection "All System" This will actually cause all
other collections that is limited to "All System" to be
evaluated. This is will in turn have an adverse impact on the SQL
performance. http://www.amazon.com/Kent-Agerlund/e/B008A01KS8
- Do not use incremental updates, because you will suffer from a cumulative performance issue from David's Blog http://www.david-obrien.net/2014/05/configmgr-collection-updates/ if a lot collections have incremental updates turned on. MS recommend you have not more than 200 collections turned on for incremental updates. https://technet.microsoft.com/en-us/library/gg699372.aspx
And thank you to Senthil's blog as well to help me understand better:
I hope this article have help you to understand your SCCM collection better. :)
SY
Wednesday 10 June 2015
Log File Investigation Part 4 (Software Updates Log Reading)
Yes it is been a while since I blogged as I was trying to fix up my VM lab, plus I am doing up several implementation document for SCCM 2012 R2, that is why, I haven't blog since, but I will blog more and share soon as my lab is ready and I have more things to cover :)
Just in case you miss it, the below were the previous three blogs that I have covered in trouble-shooting in different deployment scenarios (It's two for now, more coming up):
Log File Investigation Tool (Part 1)
Application Deployment Log Investigation (Part 2)
Package Deployment Log Investigation (Part 3)
Today, we are going to spend time on Windows Update deployment, these days, administrators face a enormous task to ensure that the organisation's machines are patched on time. Therefore SCCM 2012 R2 is your best patching companion .
So the process of getting your computers patch is already a full page topic. But for the benefit of readers I have come up a simple patching flowchart for client machines:
Because the chart does not account for CAB meetings and approval timeline you should know that the 1 month time frame is just an estimate.
Next windows update, what log files we should be looking at?
https://technet.microsoft.com/en-us/library/bb693878.aspx
Of course you could go through every log file, but let us focus on several logs files that in my opinion will be the fastest way to see the issue the client is having. First the log files to look at:
WUAHandler.log: Provides information about when the Windows Update Agent on the client searches for software updates.
UpdatesHandler.log: Provides information about software update compliance scanning, and the download and installation of software updates on the client.
Why go through WUAHandler first because it allows you to see the GUID number of the patch that the client machine needs to install. In this log, you will know how the system decide for the client machine what patch to be installed.
But the main reason is to see the GUID number so that you can trace the UpdatesHandler.log. So here you get to see the GUID number of the software update:
In this screenshot from my lab machine, you get to see the patch that is required and the GUID number accompanied with it.
Next UpdatesHandler.log:
Just in case you miss it, the below were the previous three blogs that I have covered in trouble-shooting in different deployment scenarios (It's two for now, more coming up):
Log File Investigation Tool (Part 1)
Application Deployment Log Investigation (Part 2)
Package Deployment Log Investigation (Part 3)
Today, we are going to spend time on Windows Update deployment, these days, administrators face a enormous task to ensure that the organisation's machines are patched on time. Therefore SCCM 2012 R2 is your best patching companion .
So the process of getting your computers patch is already a full page topic. But for the benefit of readers I have come up a simple patching flowchart for client machines:
Because the chart does not account for CAB meetings and approval timeline you should know that the 1 month time frame is just an estimate.
Next windows update, what log files we should be looking at?
https://technet.microsoft.com/en-us/library/bb693878.aspx
Of course you could go through every log file, but let us focus on several logs files that in my opinion will be the fastest way to see the issue the client is having. First the log files to look at:
WUAHandler.log: Provides information about when the Windows Update Agent on the client searches for software updates.
UpdatesHandler.log: Provides information about software update compliance scanning, and the download and installation of software updates on the client.
Why go through WUAHandler first because it allows you to see the GUID number of the patch that the client machine needs to install. In this log, you will know how the system decide for the client machine what patch to be installed.
But the main reason is to see the GUID number so that you can trace the UpdatesHandler.log. So here you get to see the GUID number of the software update:
In this screenshot from my lab machine, you get to see the patch that is required and the GUID number accompanied with it.
Next UpdatesHandler.log:
Do a search base on the previous GUID number and you get to find several lines of information in this log, the above log is trying to show case the installation percentage.
Next after installation it will give a status message, in this screenshot you will see actually it is pending to reboot after the patch has been installed.
Lastly it will the reboot option for the patch. This is of course determined during your software update deployment.
Hope it helps.
Happy Investigating :)
SY
Wednesday 3 June 2015
SCCM 2012 R2 Design Thoughts
Having to read and watch a lot of materials on SCCM 2012 R2 from Microsoft and SCCM MVPS, coupled with own implementation experience, I have actually consolidated a set of design principles which can be a good reference to implement your SCCM 2012 R2.
This document is good for standalone primary setup which should satisfied most of the scenarios if you have less than 2,000 client machines to handle in the environment. If you have more than 10,000 clients, you could use the client facing components like DP and MP out of the box, use your existing file server to become a DP or MP to save cost.
Of course you can try your hands at CAS implementation etc, the design principles have details of CAS hardware requirements etc, this can be use as a reference as well. With that I would like to thanks MVP Brandon Liew who has help me to read through the document.
You can download the PDF version here:
http://1drv.ms/1I7PcHo
Happy reading. :)
SY
This document is good for standalone primary setup which should satisfied most of the scenarios if you have less than 2,000 client machines to handle in the environment. If you have more than 10,000 clients, you could use the client facing components like DP and MP out of the box, use your existing file server to become a DP or MP to save cost.
Of course you can try your hands at CAS implementation etc, the design principles have details of CAS hardware requirements etc, this can be use as a reference as well. With that I would like to thanks MVP Brandon Liew who has help me to read through the document.
You can download the PDF version here:
http://1drv.ms/1I7PcHo
Happy reading. :)
SY
Subscribe to:
Posts (Atom)