DexterPOSH's Blog

While working on the previous post on exploring Discovery methods with PowerShell I came across this awesome post on creating custom DDRs with PowerShell in ConfigMgr07. http://marcusoh.blogspot.in/2010/10/sccm-custom-data-discovery-records-ddrs.html The above post explains how to create custom DDRs using ConfigMgr SDK for ConfigMgr 07. So I got tempted to immediately try it out in my ConfigMgr12 environment and found out that there exists another cool way shown by Adam Meltzer  (using C#) in his blog to create DDRs in ConfigMgr12. So in this post will try to cover : Create DDRs using COM Interface (DLL used : smsrgenctl . dll ) Create DDRs using the new DiscoveryDataRecordFile Object Interface (DLL used:  Microsoft.ConfigurationManagement.Messaging.dll ) Note : Both the above DLLs are part of ConfigMgr 2012 SDK. Create DDRs using COM Interface (DLL used : smsrgenctl.dll) Tried loading the smsrgenctl.dll from PowerShell using Add-Type , System.Reflection.As

This post is inspired by one of the activities which we had to recently do. We have a lot of branch DP's where we want to cleanup all the obsolete packages (which are not used anymore). This can be done manually by going in the ConfigMgr Console Packages node and updating the DP's manually for each package. But where is fun in doing that ...Lol I couldn't find much on the internet ..So I tested it in my Lab first and then in QA in our environment and then did it in PROD. For this post demonstration I am showing this on my LAB (ConfigMgr12) but it does work with ConfigMgr07. Note - ConfigMgr 2012 R2 has this cmdlet  Remove-CMContentDistribution which can do this but am showing the method which will work with all ConfigMgr versions (hopefully). Right now I have distributed 3 packages to the only DP (DexSCCM) in my environment. Now we can get the same Information about which DP the particular package is Distributed by querying the SMS_DistributionPoint Class.

So my lab is all setup. Now before starting to manage Objects (Computers, Users etc. ) we need to discover them. If you want to read more on Discovery in ConfigMgr, you can browse to this link . For this post am trying to automate things done in this post at Windows-Noob . Note - To manage ConfiMgr using PowerShell one needs the ConfigrationManger Module (this is available after you install Admin Console on a Client/ Server) loaded in the session, which can be done in two ways: You can open a PowerShell session and import the ConfigurationManager module. Import-Module -Name "$(split-path $Env:SMS_ADMIN_UI_PATH)\ConfigurationManager.psd1" Using ConfigMgr Admin Console you get an option to connect using PowerShell which essentially does the same thing done in above step. Note: To run all the CM Cmdlets your location needs to be set to the CMSite and properties you reference are case sensitive. Below is the Screenshot showing that : Now see th

Recently decided to embark on this little adventure of mine...where I will setup my SCCM 2012 R2 Lab and try doing most of things using PowerShell. I know this is ambitious and might take longer (even longer to blog about it)......But that hasn't stopped me in past. I am sure I will learn a lot in the process. So for this post it is the installation am focussing on and I am following the Windows-Noob Guide here . Steps which I won't be doing using PowerShell will be mentioned. My LAB : 1.  DexterDC   --  Domain Controller [Domain name - Dexter.com] (server 2012 R2) 2. DexSCCM -- Machine where SCCM will be installed (Server 2008 R2) 3. DexClient -- Windows 7 Client To make my Quest easy, I have enabled PSRemoting in the Domain using GPO. Step 1. Create the Lab Environment Create AD Users First let's create the Users and then try to give the permissions needed. * SMSadmin, a domain user  * Testuser, a domain user * Testuser2, a domain user * Testuser

I have lot of PowerShell Script which I want wrapped as an executable using PowerGUI (as PowerGUI Pro is free now). PowerGUI lets you do that easy..... After this it gives you option to name the exe , .NET version to target, Hide/Show console window in the back-end, Password protect your source etc. I thought maybe putting password will protect my source and was curious how does it really works.  But it works a bit differently then I thought. When you share this with your colleagues then in order for them to use this exe you need to share the password above. In this case I have a simple script which creates a simple UI and asks for a Computer name to reboot. When I give a wrong machine name it throws me an error and if you see the highlighted entry it points to a PS1 . If I go to the path in the error message I can see the source lying around: Now I haven't put any hard-coded credentials on it (BTW that's a bad practice ). Though