Search This Blog

Tuesday, December 7, 2010

Integration App-V and SCCM

Microsoft Application Virtualization Technical Overview



Realize greater efficiency and responsiveness for software deployments and updates.


Application virtualization is at the heart of Microsoft Application Virtualization (App-V). It decouples applications from the operating system and enables them to run as network services. Application virtualization can be layered on top of other virtualization technologies—network, storage, machine—to create a fully virtual IT environment where computing resources can be dynamically allocated in real-time based on real-time needs. App-V's patented application virtualization, dynamic streaming delivery, and centralized management technologies make everything from deployments and upgrades to migrations and business continuity initiatives easier and faster with better agility:



Application virtualization: Enable applications to run without the need to visit a desktop, laptop, or terminal server. Applications are no longer installed on the client—and there is minimal impact on the host operating system or other applications. The most extensive virtualization technology on the market, App-V virtualizes per user, per application instance, as well as key application components. As a result, application conflicts and the need for regression testing are dramatically reduced.


Dynamic streaming delivery: Applications are rapidly delivered, when needed, to laptops, desktops, and terminal servers. In most cases only a small percentage of the application is needed to launch the application. Additional components are delivered when transparently requested by the application. This results in faster delivery of the application when needed.

Centralized, policy-based management: Virtual Application deployments, patches, updates, and terminations are more easily managed via policies, and administered through the App-V console or via your ESD system. Use Microsoft App-V Application Virtualization to help reduce the complexities inherent in enterprise application management. With App-V you can reduce challenges and transform your computing environment into a dynamic, services-oriented infrastructure.


The diagram illustrates the key components of Microsoft App-V Application Virtualization.


How to integrate App-V with SCCM without losing the features you care about
 
- ◦      Control of the App-V client is seized by the SCCM client. If you had App-V running on its own before you enabled the integration, you’ll notice that all App-V apps that are published through App-V’s Publishing Server are now rendered invalid. On launch you’ll get a “Unable to initialize package information (0×00000000)” error.





- ◦    You must now publish your App-V apps through SCCM as “Virtual Application Packages”. This works by importing the .XML file of the App-V package. SCCM will distribute the packages to its Distribution Points and you can enable those Distribution Points for HTTP(S) streaming.


- ◦    To get the App-V apps to your clients, you’ll have to create SCCM advertisements. Basically SCCM advertisements replace the App-V Publishing Server. The behavior of getting App-V apps to your desktop now becomes eerily similar to SCCM’s way of installing applications. No more getting your shortcuts immediately upon logon (like you get with App-V); you will have to go get a cup of coffee and hope that SCCM is willing to give you your apps today.



- ◦    If you created non-mandatory assignments, then you’ll have to go to Add/Remove Programs yourself and click “Run” for all the apps that you want. However clicking “Run” doesn’t actually run your app, it only registers the App-V app with the local App-V client. Don’t expect to see any progress bar or visual feedback that the registration actually happened; just keep scouring around in your Start Menu in hope of finding the shortcuts for your new app.


- ◦    If you created mandatory assignments, you’ll get one or more notifications from SCCM (after some time ofcourse) that SCCM has App-V apps for you that it would like to register with the local App-V client. It will do that on *every* desktop you logon to. Prepare to spend quite a bit of quality time with the SCCM Client…


- ◦    If you’re using either Windows Terminal Services or Fast User Switching in Vista, you’re SOL because the SCCM Client is allergic to terminal sessions. You’ll get a message telling you that “No programs are available to run from a Terminal Services session”. How nice. If you happen to be running the console session, you won’t notice this limitation because at the console session, everything works just fine. So make sure you also test your solution via a terminal session so you won’t get caught by surprise.


As a result of the findings described above, we were pretty disappointed with the solution and decided to reverse our decision to integrate App-V with SCCM. However we did like the idea of using SCCM Distribution Points to stream App-V apps from. So we had a go at doing a manual integration of App-V with SCCM so that we could use just the SCCM parts we wanted


In his article he never got around to actually testing if it was possible to stream an application that was published by App-V’s Publishing Server from an SCCM Distribution Point. He only verified that is was possible to install the App-V app through an MSI with SCCM. So we ventured to get HTTP streaming working against SCCM Distribution Points, with the shortcuts still being provided by an App-V Publishing Server. In a nutshell: it works! You do have to setup a few mechanisms to get load balancing working though.



Here is how it works:


- ◦    First and foremost: disable the App-V integration with SCCM. To do this, go to the SCCM Console -> Site Database -> Site Management -> -> Site Settings -> Client Agents -> Advertised Programs Client Agent -> Properties and make sure “Allow virtual application package advertisement” is NOT selected.


- ◦    Enable your SCCM Distribution Points for BITS, HTTP and HTTPS content transfer. To do this, go to the SCCM Console -> Site Database -> Site Management -> -> Site Settings -> Site Systems -> -> ConfigMgr distribution point -> Properties and select “Allow clients to transfer content from this distribution point using BITS, HTTP and HTTPS”.


- ◦    We found that (at least in the RTM version of SCCM 2007 R2) you don’t have to enable “virtual application streaming” on the “Virtual Applications” tab of the distribution point to be able to stream from a SCCM DP when using our manual integration. The added benefit of this is that you can now also use Secondary Site DP’s as streaming servers!


- ◦    Set up an App-V Management Server on any server you like. You can even set it up on a SCCM server, it doesn’t matter. Use the default installation settings for the entire installation. After installation, set the Default Content Path to the following: http://%SFT_SOFTGRIDSERVER%


- ◦    Add an App-V package to SCCM for distribution and streaming:


- ◦    Go to the SCCM Console -> Site Database -> Computer Management -> Software Distribution -> Packages -> New -> Package. Enter the information about your package and click Next. Select “This package contains source files” and set the Source Directory to the location of your App-V package and click Finish. Note that you import the App-V package as a normal SCCM package and NOT as a Virtual Application Package. Importing it as a Virtual Application Package will cause the .SFT file in the App-V package to be renamed and cause the .SFT file to be added to not 1 but 2 locations on each SCCM Distribution Point, doubling storage requirements.


- ◦   When the package is added to SCCM, find the Package ID and use it to update the streaming location in the App-V OSD files. For each OSD file in your App-V package, update the HREF statement to HTTP://%SFT_SOFTGRIDSERVER%/SMS_DP$/SMSPKG//
(If you are using a File Share Distribution Point, the IIS vdir may be different than SMS_DP$. Verify the vdir name in IIS Manager and ensure that all DP’s are either standard DP’s or File Share DP’s.)


- ◦    Now add some SCCM Distribution Points to your package so that SCCM can distribute the App-V content


- ◦    Import the same App-V package into the App-V Management Server so that you can distribute the shortcuts and set permissions:


- ◦    On the App-V Management Server, go to the App-V Management Console, go to Applications
-> Import Application and go to the same App-V package folder. Select the .SPRJ file and click Open. Perform your regular App-V import steps and finish the import.


- ◦    The imported applications in the App-V Management Console should now show the correct http:// paths to both the OSD file(s) and the SFT file(s).


- ◦    That’s it! Now just configure your App-V Clients on the desktops to use your newly setup App-V Management Server by configuring a Publishing Server and use Group Policy to set the %SFT_SOFTGRIDSERVER% to the name of a SCCM Distribution Point nearby. We set this variable to DNS name that uses DNS Round Robin to distribute the load to multiple DP’s.


Virtual Apps – Configuring SCCM


The first thing we have to do in SCCM is make sure our distribution points are enabled to deliver a virtualized app.  You do that by going to any site system that is a distribution point and selecting properties on the distribution point component.  From there we need to ensure two settings are enabled.  First, on the general tab, make sure the ‘Allow clients to transfer content from this distribution point using BITS, HTTP and HTTPS is enabled
Next, on the ‘Virtual Applications’ tab, place a check mark to enabled the distribution point to serve virtual apps
Then, enabled the advertised programs client agent to accept virtual application distributions as follows



Now we are ready to create a virtual app package.  In the SCCM console, navigate to Computer Management > Software Distribution > Packages.  Right click on packages and select New > Virtual Application Package.  On the first screen browse to the location of your virtual app package, specifically the XML manifest

click Next and the information on the General page will be supplied for you based on the XML details.  Supply any additional information or change as needed.  Click Next on the General page and you will see the Data Source page

click Next and the information on the General page will be supplied for you based on the XML details.  Supply any additional information or change as needed.  Click Next on the General page and you will see the Data Source page

On this page, supply the UNC path to the directory that will serve as the SCCM source directory for this virtualized app. SCCM will make appropriate modifications to the package and copy contents to this directory. This is done to ensure SCCM has it’s own version of the package source to which changes can safely be made without affecting the master source directory for the virtualized app.



The remaining screens of the wizard are standard so we won’t show screenshots. When the wizard is finished we will have a new virtualized app package noted by the unique icon.


If we look at the SCCM package source for our virtualized app we notice a couple of changes. Compare to the screenshot above when we first created the sequenced package – note that a few files have not been copied over. SCCM only pulls over the needed files. Also note that the .sft file has been renamed with the SCCM package ID instead of the original file name.


Like in normal software distribution, add your virtualized app package to a distribution point enabled for delivering virtual apps and then create an advertisement.


When you create the advertisement note that there is no unique option for sending a virtualized app – just choose the standard advertisement option. The pages of the wizard are standard until you get to the ‘distribution points’ tab. Here you noticed that SCCM detected the app is virtual and is presenting you options accordingly




OK, all done, we are ready to stream the app on our SCCM clients – right? Well, maybe – first we have to make sure the app-v client is installed on all of our SCCM clients that will receive the virtual app because the app-v client piece is the one that actually runs the app. So, lets pause here and look quickly at an SCCM client that has the app-v client installed and has received policy indicating it should run the virtual app we just advertised.



App-V Client


When we open the app-v client console we have several nodes available – application, file type association and publishing servers. If we right click on the op node, application virtualization [local] and go to properties we can see general information about the app-v client. A couple of tabs are worth pointing out here


The ‘general’ tab shows us information about where log files are located, allows us to increase the verbosity of our logs and shows us the default user data directory.



Remember the Q: drive? The ‘file system’ tab shows us the default drive letter that will be used to execute virtual apps. If you modified the drive letter from Q: to something else on your sequencing system you should modify it here too.


Looking at the applications node of the app-v client console we can see our word viewer package has arrived


Going to properties on the word viewer application we can see the details the app-v client will use to execute the application.


Notice the package URL points to my SCCM distribution point. In the case of my test app I’ve configured that streaming will occur from the distribution point. If I had selected to stream from the local cache the URL would point locally to my SCCM client cache folder.


App-V Package and SCCM Client


OK, now on to actually launching the virtual app. First, if we look in the ‘run advertised programs’ control panel applet we see that the virtual app is arrived and is available to run


Just like a normal advertisement you can choose whether to make the virtual app run with a mandatory schedule or make it optional. If the choice is mandatory you much choose the option to ‘allow user to run independent of assignment’ for the app to show up as it does above.



OK, now, finally, it’s ime to run the virtual app! When the app executed all it did was place a shortcut on my start menu so the user can see the available app.


When we click on the app for the first time there will likely be a slight delay to start the app. After that, it’s very quick. The only indication that the app is running virtual is a small progress bar in the right hand bottom corner of the screen when the app launches
Besides that, you can’t tell that word viewer is running virtually. It launches and works just like it would if it were installed locally.



Notice a Q: drive is listed, noting that the application is running virtually – the drive is actually accessible through my virtual app but if you try to access the Q: drive from a cmd prompt you will get an access denied message – and the drive doesn’t even show up in ‘my computer’




Thanks:
           Habib


Tuesday, November 2, 2010

SCCM Right Click Tools (NEW) Version 2.0 (4/1/2010)

SCCM Right Click Tools



This is version 1.1 of the SCCM Right Click Tools. It will check for the installation of the SCCM admin console and if it does not find it the installation will exit.

Special thanks Ken Delikta he is the man behind the curtain, and also thanks to John Marcum for the changes he made to my original tool.

Version 1 includes: (This tool will not work with SMS 2003)

1.    Most of the tools that were included in the original SMS Console Additions V1.4 (thanks to those guys)
2.    The ability to see the computer details and security compliance web reports for a single client inside collections
3.    A separate drill down for client logs as well as security update client logs.
4.    The ability to check the status of an advertisement with a right click from that advertisementIn order to get the client and the advertisement web reports to work you must perform the following. Version 1.2 adds

1.    Fixed the right click tools on the “collections” that didn’t open a CMD window when running. Also fixed the echo so the results now show up in a command window

Version 1.3 adds

1.    Will detect the version of the tool installed so re-installation of unnecessary files does not occur when new versions are released
2.    Now has an entry in Add Remove Programs which enables un-installation of the program

Version 1.4 (4/9/2008)

1.   No more hard coding of your site code to get scripts and reports to run correctly
2.   Detects and uninstalls any previous versions of the tool.
3.   Right click tool added to the software updates node, but it only works if there is a update list with patches deployed.
4.   Prefixed each tool with your SCCM site code for easier recognition
5.   Right click ability on each advertisement that will display three web reports
6.   Added a prompt to see the CCMsetup.log on the SCCM Client install
7.   Fixed the Client Action for User Policy Evaluation and Update
8.   Added all the client actions from the control panel including the Security Updates Scan and Security Updates Deployment Evaluation

Version 1.5 (5/21/2008)

1.   Added an extension to the client tools that will tell you what collection a user or system belongs to. Thanks to Matthew Hudson
2.   Added a web report to show all the advertisements for a certain system.

Version 1.6 (5/30/2008)

1.   CCM and CCMSetup directories now work properly.

Version 1.7 (6/17/2008)

1.   Added the Software Updates Scan Cycle to the Collection root so it runs not just on one client but a whole collection. Requested by a member from the forum community.

Version 1.8 (2/13/2009)

1.   Added Support for Windows 2008 64bit.
2.   New Tool to Re-run advertisements from a drop down list.
3.   Added the ability to run client actions from the Query results.
4.   Fixed issue with script.bat

Version 1.9 (3/24/2009)

1.   Added Reboot/Shutdown options for client machines.

Version 2.0 (4/1/2010)

1.   Repleaced some of the VB scripts with custom HTA's
2.   Added new code to make the install easier
3.   Complete rewrite of some of the tools

http://myitforum.com/cs2/blogs/rhouchins/0401ConfigMgrTools.zip

Friday, October 29, 2010

SCCM 2007 R2: Installation on Windows Server 2008 - AD Preparation

SCCM 2007 R2: Installation on Windows Server 2008 - AD Preparation

To be able to install SCCM 2007 R2 we need to fullfill some pre-requisites and implement some best practices. In this article I will describe those two relartion to Microsoft Active Directory.


1. Active Directory Preparation

To have a save environment for SCCM 2007 R2 as well as for SQL Server 2005 it is a best practice to create server accounts. These accounts need to be created and will be used during the installation of SQL Server 2005 and SCCM 2007 R2. These accounts will have to be high secure as they will have "Domain Admin" permissions form within the Active Directory

1.1 Active Directory Users and Computers
Within the “Active Directory Users and Computers” snap-we need to create two groups. In this article we also create two new active directory OU's in which we will place the to be created accounts and groups.

1.1.1 Admin OU's
The creation of Ou's within the "Active Directory Users and Computers" snap-in:
Select with a right click the root of the domain and select the option: %Domainname%\New\Organizational Unit


From the wizard that appears enter the following value: Admin Groups


Click on à OK to actually create the OU

Repeat the steps but now create an OU with the value: Admin Users




1.1.2 Admin Groups

The creation of Admin Groups within the "Active Directory User and Computer" snap-in:
Select with a right click the the OU named “Admin Groups” en select the option: %Domainname%\New\Group


In the wizard that appears enter the follwing values:

Group Name: SQL-Admins
Group Name (pre-Windows 2000): SQL-Admins
click on à OK to actually create the “Group”
Repeat these steps but now create a group with the values:

Group Name: SCCM-Admins

Group Name (pre-Windows 2000): SCCM-Admins
This will result in having the two groups created:

1.1.3 Add the "Admin Groups to the “Domain Admins” group

To have the correct permissions for user accounts member of the Admin Groups we will add the newly created groups to the "Domain Admins" group.
In the OU “Users” the group “Domain Admins” with a right click and select the option "Properties”

In the properties screen select the tab “Members”

Click “Add” to add the created groups:


· SCCM-Admins

· SQL-Admins
Click on à OK to save changes

1.2 Admin Accounts
Within the installations of SCCM 2007 R2 and MS SQL 2005 we will use admin accounts to be able to logon and manage the different systems therefore we create two accounts. These accounts will have "Domain Admin" permissions as these will be added to the previously created groups. This means that the password used for these accounts will have to high secure.
Creation of the "Admin Accounts” for SCCM 2007 and SQL Server 2005 from within the "Active Directory Users and Computers" snap-in:
Select the OU named “Admin Users” with a right click and select the options: “Admin Users”\New\User

In the wizard that appears enter the following values:

First Name: SQL
Last Name: User
Full Name: SQL Admin
User logon name: SQL-Admin
User logon name (pre-Windows 2000): SQL-Admin
Click on à Next

Enter the password for this user and select the option:

(X) Password never expires
Click on à Next
Click on à Finish to create the account.
Repeat these steps to create anbother account with the following values:
First name: SCCM

Last name: Admin
User logon name: SCCM-Admin
User logon name (pre-Windows 2000): SCCM-Admin

1.2.1 Group Membership "Admin Accounts"
The created accounts will be added to the correspondig groups also created. It is a Microsoft best-practice to assign permissions to groups instead of single user or computer accounts.
Add the "Admin Accounts" to the correct groups:
Open the properties of the group "SCCM-Admins"
Select the tab “Members”
Click on    -- Add to add the follwoing accounts:

SCCM-Admin

· %Computername% of the computer that will be deployed as the SCCM 2007 R2 Server
Click on à OK to save your changes
Open the properties of the group "SQL-Admins"
Selecteer the tab “Members”
Click on à Add to add the following account:

· SQL-Admin

Clik on à OK to save your changes
This concludes the preparation within Active Directory so far. Later, during the installation of SCCM 2007 R2, we will return to do some more AD Preparation. The created groups and user accounts can now be used within the installation of SQL Server 2005 and SCCM 2007 R2.

The Configuration Manager Documentation Library Update for October 2010 is now live on the web

Coming from the System Center Configuration Manager documentation team is news that the Configuration Manager documentation library (http://technet.microsoft.com/en-us/library/bb680651.aspx) has been updated on the Web with updates from September and R3 content in October. Topics that were updated for September have Updated: September 1, 2010 at the top of the topic and topics that were updated or created for R3 have Updated: October 14, 2010 at the top of the topic.







There will be a new version of the help file available for download with the Help File Updater soon - stay tuned.
-For all the details including What's New in the Configuration Manager Documentation Library for September 2010 see :
http://blogs.technet.com/b/configmgrteam/archive/2010/10/20/announcement-configuration-manager-documentation-library-update-for-october-2010.aspx

-Documentation:
http://blogs.technet.com/b/configmgrteam/archive/tags/documentation/

Thursday, October 28, 2010

Configuring SCCM and Branch Cache

Branch cache is a feature introduced with Windows 2008 R2 that allows systems within the same subnet and separated from a content source (such as a WSUS server) to share downloaded content locally rather than each system having to traverse a latent network link back to the content source. Branch cache has two modes of operation – distributed cache mode and hosted cache mode. SCCM only supports distributed cache mode.


As mentioned, branch cache is a function of the OS and not of SCCM but, with the release of SCCM SP2, we now are able to leverage branch cache on enabled servers. When we find branch cache enabled we use it – there is no special SCCM configuration requirements for branch cache other than what is likely in se in most environments anyway. We will highlight those shortly but to start a diagram of a sample configuration might help explain how this is all setup.



In the diagram we have 4 systems. The SCCM SP2 site server, an SCCM distribution point being hosted on a Windows 2008 R2 server that has branch cache enabled and two client systems – one server and one workstation. We have mentioned already that to support branch cache we need to use a Windows 2008 R2 system – but what about clients? From the diagram note that branch cache is supported natively on Windows 2008 R2 and Windows 7 – and with the addition of BITS 4.0 clients can also take advantage of branch cache on Vista SP1 and Windows 2008 SP1/SP2.


The diagram shows how SCCM works with branch cache. The first time content is requested from the distribution point the client has no choice but to retrieve it across the latent network. Once retrieved the content is stored by branch cache. When the second client attempts to retrieve the content it detects a latent network and sends out a request for any peers with the content. The first client responds and serves up the content thus avoiding the need to pull it across from the distribution point.

OK, so we have the general concept of how it works – so how do we set it up? It’s fairly easy. First, what are the requirements in SCCM to make use of branch cache. We need our distribution point to be installed on Windows 2008 R2 and to be BITS enabled.

The only other requirement is that your advertisement be set to download and execute locally.

Both of these settings are common in most environments and are all that is required on the SCCM side. There is no selection in SCCM to ‘enable’ branch cache – with the settings above it just happens.


So how do we configure branch cache on the OS side? Just a few settings to configure. First we need to enable branch cache – let’s start with the distribution point. In Server Manager, select features and add the branch cache feature. There is no configuration here – the feature is either on or off. Once installed you will see it in the feature list.

Next, we have to configure branch cache on our clients. This can be done through local policy on each system or – much easier – through domain policy. On my domain controller I open the group policy management console. In my lab I created an OU for just the systems I want to enable for branch cache and I created a GPO to enable branch cache.


Editing the properties of the GPO we have two places to configure. First, is branch cache policy. Here we enable branch cache, set distributed cache mode, define the speed that we consider to be a latent network (default 80 ms) and configure the percentage of disk space to allocate to branch cache activity.


Note that the one option we did not configure was to enable hosted cache mode. Why? Remember, SCCM only supports distributed cache mode so, for SCCM, there is no need to enabled hosted cache mode.

A word about hosted cache mode. The OS documentation that discusses branch cache discusses both modes of operation and discuses steos to configure SMB file transfers through branch cache. To me, the documentation is a bit fuzz. From what I can tell, configuring branch cache to support SMB requires some additional configuration on the content server – such as enabling a role service called ‘branch cache for network files’ and configuring specific shares to support branch cache using the ‘share and storage management tool’. Since SCCM uses branch cache via BITS there is no need to do this additional configuration to support SMB.

In addition to the above we must configure the windows firewall to allow branch cache specific communication as follows:

Both the inbound and outbound firewall rules are accessible on the predefined list – so configuring them is as easy as selecting from the drop down menu when configuring a new rule.

OK, so all of this is configured – how do we know if it’s working? To test, I setup a package and advertisement. When testing it’s important to understand that once the package is downloaded and cached, you have to either modify the content or setup a new package because unless there is a change, clients will always pull the content from the cache after the first download due to the latent network conditions.

For the test, I start with a fresh package. The client that will download the content first will have to go to the distribution point – nothing will come from the cache since no content has yet been downloaded.

With all of this I’m ready to start the download but to simulate a latent network in my lab I must first start a tool that will ‘inject’ latency into the network connection between the distribution point and my first client. I’ll use a tool we have internally to introduce a 30 ms latency – I will maintain this latency throughout my testing. Note that my policy settings above consider any network more latent than 20 ms to be slow.

With all of this configured, I start my advertisement which initiates a download of content.
At the end of the download I run the advertisement and then move on to my second machine. This second machine is where we expect to see branch cache in action.

I prepare to run the same advertisement on the second machine – note you can tell that this advertisement has never been run before on my system – which is important when testing branch cache.

I’m about to hit run but how can I tell whether branch cache actually fires up? Performance monitor. With performance monitor you can determine whether content is being transferred from the local branch cache or from a branch cache partner vs. the network. The chart below shows a chart of perfmon counters that you get from the branch cache object. The two most interesting are the Bytes from cache and Bytes from server. If content is being retrieved from either a systems local branch cache or a peer systems branch cache, that counter will show activity. In our test case and on the second system, no content for this advertisement has ever been downloaded before so we expect content to be retrieved from our peer client that is branch cache enabled.

We initiate the advertisement as before and downloading begins.

We allow the download to finish, complete the advertisement and then look back at our performance counter numbers to see what happened.

By looking at our counters we can see that we did pull the content from our peer caching partner – so branch cache worked.

Another way we can tell that our package came over from branch cache is by looking in the event log on the system as show below. Look for event 60 and on the detail tab look for the peerProtocolFlags value. If it is set to 1 then branch cache was used to deliver the content. Thanks to my colleague Frank for the tip!



Branch cache is just one more option available to administrators to help deliver content to clients efficiently and reduce load on the network. It’s not difficult to setup and offers notable performance advantage – defiantly worth taking a look.

Microsoft System Center Configuration Manager (SCCM) Dashboard

System Center, in particular Config Manager aka SCCM, is becoming more and more popular with customers and clients at work. People looking to start enhancing and automating tasks such as OS deployment, app distribution, patch management etc as well as those who’ve started down this path, often with Altiris, and are now looking for a more rounded solution, are all asking for/happy to listen to information about SCCM. There’s more info on SCCM as a product here but in this post I specifically want to talk about the Dashboard that’s in beta.




About the Dashboard

System Center Config Manager Dashboard’s aim is to make it even easier for IT administrators to access and digest key information about their network and infrastructure, quickly and effortlessly even when not at the Management Console. The Dashboard lets you:



Track OS & App deployments

Track Security updates

Check the health status of computers

Check compliance with IT regulations

all via a customizable web interface. It’s based on Windows Sharepoint Services (WSS) so it’s key features include:



•Easy access to key information without using the Configuration Manager console

•Centralized view of Configuration Manager data sets

•Data can be viewed in graph, table, or Dundas* gauge formats

•You can create custom dashboards for different departments, based on site user’s group membership.

*I will try and confirm is this is limited to Dundas or whether SAP’s Crystal Xcelsius can be used here too.



Join the Beta Program

Sign up to the English only Beta here.



How it works:

Here’s a great diagram from the technet site:







The Process Flow goes a little something like this:



•An IT Service Manager requests a new data set.

•The IT Administrator uses the Dashboard Configuration Web Part to define the new data set.

•The IT Administrator stores the configuration information for the new data set (the information is saved in the Windows SharePoint Services Content database).

•The IT Administrator adds a new copy of the Dashboard Viewer Web Part to the default Configuration Manager Dashboard and then modifies the Web part to display the new data set.

•The IT Service Manager browses to the Configuration Manager Dashboard site.

•Windows SharePoint Services queries the Configuration Manager site database as specified by the data set configuration.

•Windows SharePoint Services renders the new data set using the Dashboard Viewer Web Part.

The Technet page is here:



http://technet.microsoft.com/en-us/library/ff369719.aspx

Windows 7 Lite Touch Image Build Using Microsoft Deployment Toolkit

Preparing the Environment
To follow along through this walkthrough, make sure you have the following environment (or something similar) set up:
  • Reference computer to build the Windows 7 install. 
  • Technician computer with MDT 2010 and Windows AIK 2.0 installed.
Creating a Deployment Share
Open the Deployment Workbench on your technician computer, then right-click on the Deployment Shares node and select New Deployment Share. The New Deployment Share wizard starts. Click the Browse button and create a folder named DeploymentShare$ in the root of your disk volume:

Click Next and the share name will automatically be populated and the UNC path to the share will be displayed:

Click Next and give your deployment share a descriptive name:

Click Next and choose whether you want to be able to capture an image after deploying it to a computer. We will leave this option enabled so we can use it if we deploy a reference (master) computer and capture its image for deployment onto multiple target (end-user) computers:

Click Next and specify whether the user should be allowed to set the password for the local Administrator account on their computer. We'll leave this option unchecked:

Click Next and specify whether the user should be asked to enter a product key. We will leave this unchecked because we are deploying Windows 7 Enterprise, which means that activation is typically performed using Key Management Service (KMS):

Now finish the wizard and review the Confirmation page to ensure everything was done as expected. Figure 7 shows the newly created deployment share and its folder structure in the Deployment Workbench:

Configuring the Deployment Share
To add an operating system, right-click on the Operating Systems node in the deployment share and select Import Operating System. This starts the Import Operating System Wizard. On the first page of the wizard, specify that you want to import a full set of source files:

Insert your Windows 7 Enterprise product media into the DVD drive of your technician computer and browse to select the DVD:

Click Next and the wizard skips ahead to the Destination page. Specify a descriptive name for the folder where the source files will be imported to on your technician computer

Finish the wizard. The import process may take several minutes to complete. Once it is done and you select the Operating Systems folder in your deployment share, the imported OS is displayed.

 
At this point you would add out-of-box drivers, packages and applications to your deployment share as needed.
Creating a Task Sequence
Now let us create a task sequence. A task sequence is a series of steps that are performed during deployment. We want to create a task sequence that will install Windows 7 Enterprise onto a bare-metal target computer. To do this, right-click on the Task Sequences folder in your deployment share and select New Task Sequence. This launches the New Task Sequence Wizard. On the first page of the wizard, specify a task sequence ID (no spaces), task sequence name, and comments as desired:

Click Next and select Standard Client Task Sequence from the list of available task sequence templates:

 Base the new task sequence on the Standard Client template
Click Next and select Windows 7 Enterprise, which is the only imported OS at this point:

Click Next and select the option to not specify a product key in the task sequence:

Do not specify a product key in the task sequence when deploying volume-licensed media and using KMS activation
Click Next and specify the name of the user who will be using the computer and your organization name and website/internet:

Click Next and specify a password for the local Administrator account on the target computer:

Finish the wizard. The new task sequence is displayed in the Task Sequences folder of your deployment point:

Updating the Deployment Share
Now we need to update our deployment share. Updating a deployment share does several things, one of which being the creation of customized version of the Windows Preinstallation Environment (Windows PE) that can be used to deploy the operating system using the task sequence. Specifically, updating the deployment share in this example creates the following Windows PE images in the C:\DeploymentShare$\Boot folder on your technician computer:
  • LiteTouchPE_x64.iso – Used to manually deploy Windows 7 Enterprise x64 onto a bare-metal system.
  • LiteTouchPE_x64.wim – Used to deploy Windows 7 Enterprise x64 onto a bare-metal system using Windows Deployment Services.
  • LiteTouchPE_x86.iso – Used to manually deploy Windows 7 Enterprise x86 onto a bare-metal system.
  • LiteTouchPE_x86.wim – Used to deploy Windows 7 Enterprise x86 onto a bare-metal system using Windows Deployment Services.
To update your deployment share, right-click on it and select Update Deployment Share. This launches the Update Deployment Share Wizard:

Leave the default options selected and finish the wizard. It may take some time to create the Windows PE images on your technician computer. Once the wizard finishes, burn the LiteTouchPE_x86.iso file onto a CD as you will need it to deploy Windows 7 Enterprise x86 onto your target computer.
Note:
On the Confirmation page of this wizard (and on all MDT 2010 wizards) there are two buttons:
  • Save Output – saves the output of the wizard to a text file (actually it's better to save it as .rtf as it's more readable that way).
  • View Script – displays the underlying Windows PowerShell commands that are executed by the wizard.
As an example of the second, the View Script output from the Update Deployment Share Wizard looks like this:
Add-PSSnapIn Microsoft.BDD.PSSnapIn
New-PSDrive -Name "DS001" -PSProvider MDTProvider -Root "C:\DeploymentShare$"
update-MDTDeploymentShare -path "DS001:" -Verbose