September 2011 - Posts
Recently was working at client, we caused ourselves a slight reporting issue. We had exported all the reports from a previous site, including custom reports. When we imported those into the new site, we overwrote the stock reports. What happens when you do this is that it breaks all the built in reporting links.
You lose the links like this example below.
In order to recreate the stock reports and ensure the appropriate links are there, we simply need to duplicate the process that creates the original reports. This can be achieved by running a mofcomp against the smsrprt.mof file that is located in \installpath\bin\i386.
One you have done this, you will be able to look at the stock reports and all the links that were previously missing will now be there. This creates the original stock 332 reports, this doesn't include the AI, FSP or FEP reports that might be added when additional features are added or installed.
In addition during this process and testing, there isn't a nice way to delete multiple reports. No way to do this via the ConfigMgr console is provided. So I wrote a simple script to allow you to delete multiple reports.
The following VBscript will delete multiple reports and you can specify the ID range you want to delete. if you uncomment out the echo commands, you can be prompted as each report is deleted, but that isn't very efficient if you are deleting a lot of reports.
1: Dim objswbemservices
2: Sub ConnectToSCCM()
3: set objSwbemLocator = CreateObject("WbemScripting.SWbemLocator")
4: set objSWbemServices= objSWbemLocator.ConnectServer(".", "root\sms")
5: Set ProviderLoc = objSWbemServices.InstancesOf("SMS_ProviderLocation")
6:
7: For Each Location In ProviderLoc
8: If Location.ProviderForLocalSite = True Then
9: Set objSWbemServices = objSWbemLocator.ConnectServer(Location.Machine, "root\sms\site_" + Location.SiteCode)
10: End If
11: Next
12: End Sub
13:
14: ConnectToSCCM()
15:
16: For each objreport in objswbemservices.execquery("select * from sms_report")
17: If objreport.reportid >= 1 And objreport.reportid <= 378 Then
18: then objreport.delete_
19: 'Wscript.Echo "Deleted report: " & objreport.ReportID
20: 'Wscript.Echo "Report name: " & objreport.Name
21: End If
22:
23: Next
One of the few non-technical posts I'll make. I'm walking in the Step Out event to help support a member of my family who has diabetes.
Together we can Stop Diabetes. One step at a time.
I am walking and raising money for the American Diabetes Association's signature fundraising walk, Step Out: Walk to Stop Diabetes, because diabetes is important to me.
Please support me with a donation by selecting the "sponsor me" button.
By making a donation on my behalf, you will be helping the Association provide community-based education programs, protect the rights of people with diabetes and fund critical research for a cure.
No matter how small or large, your generous donation will help us Stop Diabetes.
Did you know that 1 in 3 children in the United States face a future with diabetes?
The Association works everyday to change the frightening future that diabetes has in store, but we need your help. Who else do you know that has diabetes? Please make a donation to my fundraising efforts on their behalf.
Together we can Stop Diabetes.
One of my previous posts has been incredibly popular. I worked with Michael Murgolo on testing a great ConfigMgr hotfix that would automatically apply hotfixes during a ConfigMgr OSD Task Sequence.
Matt Benninge has created a new version of the hotfix script with some very nice feature adds. Matt added the following features:
- Hotfixes are installed in order based one numbers. So my script installs KB2000 after KB98 where Michael’s would do the opposite.
- I always assume that the OS-disk will end up as C:, Michael’s script would not work if you had a Bitlocker partition during WinPE that was C: and OS as D: which then would become C: only after system had booted into “full OS”.
- You have the ability to exclude hotfixes with my script
- Limitation: The Hotfixes must all be located in a folder starting with “KB”, if this is not true that hotfix will be ignored.
My original post on how to install still holds true, and Matt has a post on how to use the script and some of his new features posted here.
Windows 8 preview hasn't even been out 24 hours yet and Johan Arwidmark is already putting up blog posts!
Read his full post here.
Read the original post here.
**************************************************************
This post was contributed by Lutz Seidemann, a Architect with Microsoft Services - APAC.
Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use
"Why deployment is so hard?", “Where can I find all related information?” What else I need to consider?”
Those or similar questions are normal during my customer projects. After getting the same questions again and again,
I’ve decided to create a Mindmap with all common links you need to know if you in the deployment space.
Since few weeks I’m sharing them now with the project teams and the amount of Questions I get is drastically reduced :-}
Hope this helps.
******************************************************************
Jason Sandys has a new post covering mobile device management in ConfigMgr 2012.
Read the full post here.
Mobile Device Management is a very popular topic in enterprises as of late and so the question of what (exactly) ConfigMgr 2012 will be able to manage has been coming up a lot lately also.
(Note that this information is current to the best of my knowledge for beta 2 of ConfigMgr 2012 and presumably for RTM.)
Basically, there are two types of client management in ConfigMgr 2012: light and native (these aren’t official names just my characterizations).
The following solution(s) are provided as-is without any warranty, confers no rights and is not supported by the Author(s). Use at your own risk.
Installing and configuring Configuration Manager Secondary Sites is often a manual and time consuming task. If you have 50 or more sites that can be a significant amount of time spent installing and configuring Secondary Sites. The Hydration approach attempts to resolve that issue by providing an automated way to setup and configure Secondary Sites.
The following Hydration solution can be run on an existing Server 2003 or Server 2008 R2 Operating System and will configure the necessary pre-requisites and install the Configuration Manager Secondary Site.
This document assumes the following:
· You have Microsoft Deployment Toolkit 2010 Update 1 installed
· SQL is configured to allow Named Pipes
· You have already created a SQL$ share
· You have the knowledge required to work within the MDT Deployment Workbench
The Hydration process has been tested on Server 2003 R2 SP1/SP2 and Server 2008 R2 SP1.
The files are contained in a “HydrationShare.zip” archive. Once these files are extracted, you will need to modify a few of the script files and add the required source files. This section details those required changes.
The files are provided as a self-contained DeploymentShare. You can simply extract this archive out and open the folder with the Deployment Workbench.
Sources files are required for the following items under the Applications directory in the HydrationShare.
Table 1: Required Source Files
| Folder | Description |
| \ConfigMgr 2007 R3\Source | R3 installation files |
| \ConfigMgr 2007 R3\Hotfix | R3 Pre-req hotfix 977384 |
| \ConfigMgr 2007 SP2 Secondary\PreReqs | ConfigMgr downloaded preq-reqs’s |
| \ConfigMgr 2007 SP2 Secondary\Source | ConfigMgr installation files |
| \ConfigMgr 2007 Toolkit V2\Source | ConfigMgr Toolkit MSI |
| \ConfigMgr Server 2003 IIS\i386 | I386 directory from Server 2003 media |
Extract the HydrationShare.zip archive to the location you want the HydrationShare to reside.
Once the files are extracted out, you need to share out the HydrationShare. A Hidden share is recommended.
1) Open the Deployment Workbench
2) Right-click on Deployment Shares and select Open Deployment Share
3) Select the path for the extracted HydrationShare files
4) Select Next
5) Select Next
6) Select Finish
This Hydration solution relies on a “SCRIPTSITECODE” variable. This solution was developed around this information being populated in the MDT database. It is possible to configure and set this variable through other methods, but this guide will not address those.
1) Open the MDT workbench and expand the HydrationShare.
2) Select Advanced Configuration-Database
3) Right-Click on Database and select New Database
4) Input the name of the SQL server and make sure the Network Library is selected to Named Pipes, then select Next
5) Input MDT2010 for the Database Name and select Next
6) Input SQL$ for the SQL Share, then select Next
7) Select Next
8) Select Finish
Provided with the Hydration files are 2 SQL files for extending the MDT database with the SCRIPTSITECODE value and refreshing the views.
Open the “create scriptsitecode.sql” in SQL Management Studio.
Ensure that you are pointing to the MDT database.
Once you are pointed to MDT Database. You can Execute the query.
You should see “Command(s) completed successfully”
Next open the “refresh MDT views.sql” and make sure you are again pointed to correct database.
You should see “Command(s) completed successfully”
![clip_image013[1]](http://myitforum.com/cs2/blogs/cnackers/clip_image0131_thumb_26ECFFEB.png "clip_image013[1]")
If you open up the MDT workbench, go into Advance Configuration – Database- Computers, you will now see a new property called ScriptSiteCode listed on the Settings tab.
A PowerShell script and CSV file are provided for the bulk import of computers into the MDT database. These computers are the servers we want to configure as Secondary Sites.
The CSV file contains the Description, MacAddress, and ScriptSiteCode values we want to import into the Database.
We use the MacAddress to identify the server and configure the appropriate SiteCode for the ConfigMgr installation. The SiteCode is stored in the ScriptSiteCode variable. The description is just a friendly name so we can identify the server in the database.
The provided PowerShell script will do a bulk import of the CSV file into the MDT database. The PowerShell script imports a MDT Module, connects to the MDT database and imports the information from the CSV file.
Edit the PowerShell script to make sure the paths are correct to the source files.
Edit the PowerShell script to make sure the correct SQLServer and Database are specified.
After running the import, you will see the records in the Database based on the information in the CSV.
Once you have opened the HydrationShare with the Deployment Workbench and created the MDT database, there are a few changes that need to be made for the HydrationShare to successfully work.
Under the main HydrationShare properties, make sure the share name is correct and the local path is correct for the location you have put the HydrationShare.
Under the Rules tab, make sure your [CSettings] section has the correct SQLServer and Database name.
Ensure your bootstrap.ini has the correct DeployRoot value.
Under the Rules tab, configure the AdminPassword value to match the local administrator password of the servers you will run the Task Sequence on. This allows the Task Sequence to automatically log in and continue after the required reboots. This is required for the auto-logon to work correctly.
After making the required changes, right click on the HydrationShare and select Update Deployment Share.
Select Next.
Select Next.
Select Finish.
There is a section of code in this script that allows you to specify existing source files to use, if we can find those, we will use those to install ConfigMgr, otherwise we’ll use the files from the script source files directory.
The following code would need to be changed in the script to match the location you might have local source files. It is located at line 93 in the script.
sFile = "F:\folderpath\smssetup\bin\i386\setup.exe"
There is also logic in the 2003 IIS script that checks for a local copy of the i386 directory. We look for the i386 directory at the root of the C: drive. If we don’t find it then we copy it down from the source files. In addition we set a few registry keys to let Windows know where the source files are located. If you wanted to change this location, you would need to modify the following lines of code.
Line 57 – Check for local i386
sFile = "C:\i386\setup.ex_"
Lines 70-72 – Update registry to point to C:\i386
oShell.RegWrite "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\SourcePath", "C:\", "REG_SZ"
oShell.RegWrite "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\ServicePackSourcePath", "C:\", "REG_SZ"
oShell.RegWrite "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SourcePath", "C:\", "REG_SZ"
The sender creation script is coded to the primary site. This will need to be modified to point to your primary site.
Lines 51-52
primSiteCode = "001"
primSite = "2008-configmgr"
Server 2003:
· None
Server 2008 R2:
· UAC is disabled
· Server Manager is not configured to start (R3 will fail if it detects any open MMC)
· Script is launched with administrative rights (careful of “Run” credentials)
The Task Sequence can be started by launching the Lite-Touch process from the Run box.
Use the following command:
“Cscript.exe \\servername\hydrationshare$\scripts\litetouch.wsf”
Once started, you will see the Task Sequence selection screen, select Next to continue.
On the credentials screen, provided an account that has appropriate credentials to connect to the HydrationShare. (Read Acces)
After clicking Next, the process will start. (Example screen from 2008 R2)
Download the HydrationShare here.
The following solution(s) are provided as-is without any warranty, confers no rights and is not supported by the Author(s). Use at your own risk.
Installing and configuring Configuration Manager Secondary Sites is often a manual and time consuming task. If you have 50 or more sites that can be a significant amount of time spent installing and configuring Secondary Sites. The Hydration approach attempts to resolve that issue by providing an automated way to setup and configure Secondary Sites.
The following Hydration solution can be presented in 2 forms. It can be presented as a Post Operating System Task Sequence that will configure either Server 2003 or Server 2008 R2 systems for being a Secondary Site. The 2nd method is to integrate the steps into a Task Sequence that also deploys a Server 2003 or Server 2008 R2 image along with configuring the server to be a ConfigMgr Secondary Site.
This document assumes the following:
· You have a working and properly configured Configuration Manager 2007 SP2/R3 Primary Site
· You have Microsoft Deployment Toolkit 2010 Update 1 installed
· You have integrated MDT with ConfigMgr
· You have an existing MDT toolkit package
· SQL is configured to allow Named Pipes
· You have already created at least one DeploymentShare in MDT
· You have already created a SQL$ share
· You have the knowledge of how to create the required ConfigMgr packages
The Hydration process has been tested on Server 2003 R2 SP1/SP2 and Server 2008 R2 SP1.
The files are contained in a “ConfigMgr_Install.zip” archive. Once these files are extracted, you will need to modify a few of the script files and add the required source files. This section details those required changes.
The following tables details the included file/folder structure.
Table 1: Folder Structure
| Folder | Description |
| \SQL Files | SQL files to extend MDT database and refresh views |
| \Import_Computer | PowerShell and CSV for bulk import of ConfigMgr Secondary Site servers |
| \Templates | Task Sequence template and CustomSettings.ini template |
| \Configure WebDAV | Script to configure WebDAV for Server 2008 R2 |
| \ConfigMgr Server 2003 IIS | Script to configure IIS for Server 2003 |
| \ConfigMgr Create Senders | Script to create Primary site to Child site sender |
| \ConfigMgr 2007 Toolkit V2 | ConfigMgr Toolkit (trace32) |
| \ConfigMgr 2007 SP2 Secondary | Script and source files for installing ConfigMgr secondary site |
| \ConfigMgr 2007 R3 | Script and source files for installing ConfigMgr R3 and necessary pre-requisite hotfix |
Sources files are required for the following items.
Table 2: Required Source Files
| Folder | Description |
| \ConfigMgr 2007 R3\Source | R3 installation files |
| \ConfigMgr 2007 R3\Hotfix | R3 Pre-req hotfix 977384 |
| \ConfigMgr 2007 SP2 Secondary\PreReqs | ConfigMgr downloaded preq-reqs’s |
| \ConfigMgr 2007 SP2 Secondary\Source | ConfigMgr installation files |
| \ConfigMgr 2007 Toolkit V2\Source | ConfigMgr Toolkit MSI |
| \ConfigMgr Server 2003 IIS\i386 | I386 directory from 2003 media |
This Hydration solution relies on a “SCRIPTSITECODE” variable. This solution was developed around this information being populated in the MDT database. It is possible to configure and set this variable through other methods, but this guide will not address those.
1) Open the MDT workbench and expand your DeploymentShare
2) Select Advanced Configuration-Database
3) Right-Click on Database and select New Database
4) Input the name of the SQL server and make sure the Network Library is selected to Named Pipes, then select Next
5) Input MDT2010 for the Database Name and select Next
6) Input SQL$ for the SQL Share, then select Next
7) Select Next
8) Select Finish
Provided with the Hydration files are 2 SQL files for extending the MDT database with the SCRIPTSITECODE value and refreshing the views.
Open the “create scriptsitecode.sql” in SQL Management Studio.
Ensure that you are pointing to the MDT database.
Once you are pointed to MDT Database. You can Execute the query.
You should see “Command(s) completed successfully”
Next open the “refresh MDT views.sql” and make sure you are again pointed to correct database.
You should see “Command(s) completed successfully”
![clip_image009[1]](http://myitforum.com/cs2/blogs/cnackers/clip_image0091_thumb_4311A6FE.png "clip_image009[1]")
If you open up the MDT workbench, go into Advance Configuration – Database- Computers, you will now see a new property called ScriptSiteCode listed on the Settings tab.
A PowerShell script and CSV file are provided for the bulk import of computers into the MDT database. These computers are the servers we want to configure as Secondary Sites.
The CSV file contains the Description, MacAddress, and ScriptSiteCode values we want to import into the Database.
We use the MacAddress to identify the server and configure the appropriate SiteCode for the ConfigMgr installation. The SiteCode is stored in the ScriptSiteCode variable. The description is just a friendly name so we can identify the server in the database.
The provided PowerShell script will do a bulk import of the CSV file into the MDT database. The PowerShell script imports a MDT Module, connects to the MDT database and imports the information from the CSV file.
Edit the PowerShell script to make sure the paths are correct to the source files.
Edit the PowerShell script to make sure the correct SQLServer and Database are specified.
After running the import, you will see the records in the Database based on the information in the CSV.
The following folders from the Hydration files will need be to created as Packages in ConfigMgr.
These packages will be used by the Task Sequence template. No Programs are required for the packages, simply create a Package that references the source files so we can make them available to the Task Sequence.
NOTE: The ConfigMgr Toolkit can simply be imported as a MSI.
A Task Sequence XML is provided in the \Templates folder in the Hydration files.
This template contains all the necessary steps to configure either a 2003 or 2008 R2 server for being a Secondary Site. In addition to the packages containing the Hydration files, we need to use MDT Toolkit Package and a Settings Package.
The required steps in the template need to be configured to point to the ConfigMgr packages you have created.
![clip_image024[1]](http://myitforum.com/cs2/blogs/cnackers/clip_image0241_thumb_54BDC964.png "clip_image024[1]")
A customsetings.ini for use with Task Sequence template has been provided in the \Templates folder.
The SQLServer and Database values will need to be changed to match your environment.
Ensure that the Gather step in the template is pointing to your Settings package.
There is a section of code in this script that allows you to specify existing source files to use, if we can find those, we will use those to install ConfigMgr, otherwise we’ll use the files from the script source files directory.
The following code would need to be changed in the script to match the location you might have local source files. It is located at line 93 in the script.
sFile = "F:\folderpath\smssetup\bin\i386\setup.exe"
There is also logic in the 2003 IIS script that checks for a local copy of the i386 directory. We look for the i386 directory at the root of the C: drive. If we don’t find it then we copy it down from the source files. In addition we set a few registry keys to let Windows know where the source files are located. If you wanted to change this location, you would need to modify the following lines of code.
Line 57 – Check for local i386
sFile = "C:\i386\setup.ex_"
Lines 70-72 – Update registry to point to C:\i386
oShell.RegWrite "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\SourcePath", "C:\", "REG_SZ"
oShell.RegWrite "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\ServicePackSourcePath", "C:\", "REG_SZ"
oShell.RegWrite "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SourcePath", "C:\", "REG_SZ"
The sender creation script is coded to the primary site. This will need to be modified to point to your primary site.
Lines 51-52
primSiteCode = "001"
primSite = "2008-configmgr"
The provided TS template in \templates can also be used with an OSD TS to create a Secondary Site from bare-metal. The template can simply be copied into an existing OSD TS.
Download the script files here.
TechEd Australia video featuring Michael Niehaus.
System Center Configuration Manager 2012 is a significant upgrade. Learn how this new version affects the OS deployment process, and explore the new OS deployment capabilities provided in this release.
Watch or download the video here.
Fantastic post over on The Deployment Guys blog about using USMT in a Replace scenario.
Read the full post here.
While USMT 4.0 in a Refresh Scenario provides some great advance by using Hardlinking in a Replace Scenario customers still face multiple operational challenges and potential capital costs during large scale deployments because user data needs to make its way from the legacy computer to the new computer. Managing that data and its transfer can be an expensive task.
System Center Configuration Manager does provide some help in Replace Scenarios with their State Migration Point role, but with that approach comes several operational and hardware requirements. In the short term, when managing an enterprise wide migration of a desktop operating system, as many customers are facing with Windows 7, the state migration point can potentially become a bottleneck during the migration. There is a need for more storage capacity for USMT Data on the server. Without it only so many migrations can be run at any one time. There may be additional disk subsystem IO performance requirements as well which if not addressed could slow capture and restore of USMT data. The data also needs to be transferred twice over the network which costs additional time and could make the NIC of the SMP server a potential bottleneck. In remote offices transferring USMT data over WAN links would also potentially slow down network links impacting other business functions and increasing the time a given migrations may take. Managing and tracking all of these risks is one more thing IT admins have to take into account for a migration.
Some alternative approaches that enterprises use is a more manual method where a technician uses either Easy Transfer or USMT’s core tools, Scanstate.exe and Loadstate.exe, with a USB hard drive/stick to ports the user data from the legacy computer to the new one. Those approaches do work, though operationally they can be very labor intensive and thus does not scale well when an organization is facing hundreds if not thousands of systems to migrate.
There is a third approach to consider. Both Scanstate.exe and Loadstate.exe, the core utilities for USMT have input parameters for where to save and restore data. Using that functionality, data could be captured from the legacy OS and saved directly to the new computer over the network. The benefits to this are numerous. It would defuse the network and Disk IO load across many more computers and each of their NICS and hard drives thus avoiding potential bottlenecks of a centralized server. USMT data would only have to be moved once across the network. The process could still be zero touch without the need for any manual processes beyond delivering the new computer to the end user’s desk. There would be no need to purchase additional storage or manage it for state migration points. This isn’t to say there are no costs associated with the approach, but that the engineering and infrastructure required to make it happen should be weighed carefully against other options. For some organizations this approach does make sense and if so you’ll be interested in the processes I have outlined below to make this work.
Great post over on The Deployment Guys.
Read the full post here.
One of the great features of MDT 2010/2012 is the ability to create a media based deployment – this media based deployment can be placed on a USB based memory device (HDD or Fob) or onto a DVD. This allows the MDT based deployment to run from this removable media which is great for badly connected environments or portable build requirements.
Many customers I work with like to use DVD media based deployment as MDT 2012/2012 automatically creates a .ISO file that can be burnt to DVD and in most cases this gives them up to 8.5 GB on a dual layer DVD – it’s also a cheap deployment mechanism. However there are some occasions where this amount of DVD space just isn't enough and a combination of image size and MDT distribution share content pushes the requirement for storage over the limit of the DVD. You could at this point switch to using USB based devices or you can read on and use the solution discussed in this post.