When I'm implementing ConfigMgr 2007 at customers, default collections are almost not used. Only the "All Systems" is handy for recognizing devices. Mostly I create collections for existing or new Active Directory OU's. (for example: Desktops, Laptops, VDI). When devices are placed in this OU's you can browse for this. Use "Active Directory System Group Discovery" for that, and the query can be created.
Read the blog: "Configure dynamic collections in ConfigMgr" for a complete guide to create dynamic collections.
http://henkhoogendoorn.blogspot.com/2011/01/configure-dynamic-collections-in.html
But what to do when there are no devices found in OU's, or worst, the OU's doesn't yet exist? In that case you cannot browse for this, so queries must be manually filled in. If you are specifying a full path, the FQDN of the Active Directory domain and a path to the OU is used to locate the OU in question.
So, in my example, the path is "SYSTEMCENTER.COM/VIRTUAL MACHINES" for the OU. With this information it's not needed to link ConfigMgr collections to existing Active Directory OU's anymore!
Friday, March 4, 2011
Query ConfigMgr collections with Active Directory
Labels:
Active Directory,
Collections,
Query
How to uninstall applications with ConfigMgr
With ConfigMgr 2007 it is possible to publish MSI applications. But what to do when there is an update for a specific application? In this blog I will explain what to do for removing the existing application on devices, and publish a new version of it. Then ConfigMgr is not only the recommend solution for updating App-V packages, but also for MSI applications!
First create a MSI-based application and program in ConfigMgr. Important detail is then to fill in the Windows Installer information! With this information it is possible for ConfigMgr to uninstall applications from devices. For doing this go to the "Windows Installer" tab in the program, choose Import, and browse to the MSI file of the application. Then the "Windows Installer product code" will be automatically filled in.
Do this for all MSI-based applications! With applications that are only available as EXE file, use a "EXE to MSI file" solution for creating MSI files of all applications that will be installed (and/or updated) with ConfigMgr.
Now what to do for updating the application? Best practice is to uninstall it first (or a in-place upgrade must be possible)! Create a new program (in the application itself) for that. In the program the following information must be placed:
In this case the following Command line is used: msiexec.exe /x {FC7BACF0-1FFA-4605-B3B4-A66AB382752D} /qn (example)
No need for fill in Windows Installer information in this program. Choose "Whether or not a user is logged on" on the Environment tab.
Advertise this new program to the collection where specific clients are been, and wait till the program will be uninstalled. When it is removed a new update for this application can be installed. In the Event Viewer this information can also been found.
When a update from a specific application must be done, with uninstalling the older version, the following can be done:
Create a new Software package, and choose on the Advanced tab for "Run another program first". Select the remove/uninstall program for the old application, and update the MSI application. That's all you have to do for uninstalling or updating applications!
First create a MSI-based application and program in ConfigMgr. Important detail is then to fill in the Windows Installer information! With this information it is possible for ConfigMgr to uninstall applications from devices. For doing this go to the "Windows Installer" tab in the program, choose Import, and browse to the MSI file of the application. Then the "Windows Installer product code" will be automatically filled in.
Do this for all MSI-based applications! With applications that are only available as EXE file, use a "EXE to MSI file" solution for creating MSI files of all applications that will be installed (and/or updated) with ConfigMgr.
Now what to do for updating the application? Best practice is to uninstall it first (or a in-place upgrade must be possible)! Create a new program (in the application itself) for that. In the program the following information must be placed:
In this case the following Command line is used: msiexec.exe /x {FC7BACF0-1FFA-4605-B3B4-A66AB382752D} /qn (example)
No need for fill in Windows Installer information in this program. Choose "Whether or not a user is logged on" on the Environment tab.
Advertise this new program to the collection where specific clients are been, and wait till the program will be uninstalled. When it is removed a new update for this application can be installed. In the Event Viewer this information can also been found.
When a update from a specific application must be done, with uninstalling the older version, the following can be done:
Create a new Software package, and choose on the Advanced tab for "Run another program first". Select the remove/uninstall program for the old application, and update the MSI application. That's all you have to do for uninstalling or updating applications!
Labels:
Applications,
ConfigMgr,
Uninstall,
Update
Tuesday, March 1, 2011
More handy tips and tricks for ConfigMgr deployment
Because there are many challenges to control in ConfigMgr, I will post another blog about handy tips and tricks! This time I will order them on subject, so it's easy to find the right one! Everyday there are new challenges in ConfigMgr, but still it's a cool product. This because when it works, it can do a lot for you. And with new releases and updates it can even do more!
Here the new tips and tricks section:
Windows XP:
The combination of ConfigMgr and Software Updates is not always a simple one. This because when it's not working, it's not always easy to find the solution. Here are some best practices for installing and configuring:
That's all for now, more tips and tricks later?!
Here the new tips and tricks section:
Windows XP:
- With Windows XP your image is not that big (500Mb), but many Driver packages are needed (for every device a driver package). Put all Driver packages in the Task sequence, with a query on it. That way you can have a single image, single Task sequence, for many different devices.
- Because Windows XP don't recognize SATA disks by default, put SATA drivers in the Driver packages, and select the right model in the Task Sequence! That way it's not needed to change the BIOS setting from AHCI to ATA/IDE or something like that.
- Most of time I create a Sysprep package (extract files from deploy.cab), and put the sysprep.inf file in the Task sequence. That way you are flexible, and put desktops and laptops in their own OU's!
- For having Multicast functionality with maximum results, put the source files of applications in the image. That way you're still flexible with a clean image and sources (image gets bigger), and data goes only once over the network. This because Multicast only works in WinPE mode.
- Because there are so many Software updates after Windows XP SP3, update your image with as many updates that's possible. That way deployment goes faster, and less updates needs to be installed during or after deployment. For example: only install Office updates during Task sequence progress.
- For creating Window 7 images, it's not necessary to add a product key in the Tasks sequence. Otherwise capturing the image will fail. The product key must be placed in the unattend.xml file, so installation can choose which Windows 7 version must be installed.
- With Windows 7 no large driver packages will be needed anymore. This because there is a large driver library build-in, and only specific (older) drivers must be manually added. Windows 7 is easy to install that way!
- Using sysprep, and creating a sysprep package is not necessary anymore. Just create a unattend.xml, and Windows will automatically run sysprep during deployment. Again: Windows 7 is easy to install that way!
- More tips and tricks for Windows 7 will follow later!
The combination of ConfigMgr and Software Updates is not always a simple one. This because when it's not working, it's not always easy to find the solution. Here are some best practices for installing and configuring:
- When installing WSUS, choose always for a custom website, with ports 8530 and 8531. This way the ConfigMgr Management Point and Software Updates are not both configured on port 80 and 443 (best practice).
- When WSUS is installed, check permissions on the WSUS and WSUSContent folder. On both folders the Network Service account must have the right permissions. On the WSUS folder set Read permissions and on the WSUSContent folder set Full Control permissions for the Network Service account.
- When WSUS is installed with a custom website check security on the IIS website. This must be set to Anonymous authentication, with a "IUSR_<ConfigMgr Server>" account. This must be a Domain User account, with Local Admin rights on the ConfigMgr server.
- With MP Troubleshooter (ConfigMgr 2007 Toolkit) you can check if the IIS account has enough permissions for accessing both websites. It's always necessary for having enough (local) rights on the ConfigMgr server.
- Sometimes a Proxy server must be used for synchronizing updates. Try both configurations (on and off) with or without an User account. Sometimes there must also made a bypass on the Proxy server for getting it to work.
- At last, do a "Run Synchronization" on the Update Repository and follow the Software Updates in the wsyncmgr.log (easy to see with SMS Trace - ConfigMgr 2007 Toolkit). When synchronization is done, do it again till no updates are available anymore. Then create Search Folders.
- With Search folders it's easy to see which updates has come available for the last month (example) for a specific product. This updates can be drag-and-dropped on the Update Lists for creating overviews.
- When importing drivers, only once a specific driver can be imported. With that knowledge it's not possible to create a specific folder for every hardware model. What i do most of time, is put a label (tag) on drivers, with the model number.
- When creating driver packages it's possible to have a mix of drivers (multiple hardware models). This because a specific driver can be imported once, and that driver must be available for multiple hardware models (for example).
- There is a hotfix available for importing drivers multiple times, for creating specific driver packages. This hotfix can be found at: http://support.microsoft.com/kb/2213600
- When using Dell systems, it's easy to using the "Dell Client Deployment Pack". Then the only thing you have to do is importing the CAB files, and Dell will create the driver packages for you!
- When using Dell systems, you can update or change BIOS settings with the "Dell Client Configuration Utility". Both downloads are plug-ins for ConfigMgr 2007, and will be visible in the console.
- On the Microsoft Update Catalogue, drivers can be found on specific names, or with Hardware ID's like the following:
"PCI\VEN_14E4&DEV_1677&SUBSYS_01AD1028". Just look in the details from drivers you want a specific driver for.
- There are two (2) service accounts needed, when using ConfigMgr the right way. The Network Access (NA) account, and the Push Installation (PI) account. Both accounts can have Domain User rights, but the PI account must at least Local administrator on the device then.
- When setting up ConfigMgr with minimal (Domain User) security rights, more time is needed for setting up the server(s). This because sometimes the service accounts are used, and sometimes the Primary server computeraccount is used.
- The server which is your primary site server role is the one which needs to go to the source folder. So, the computer account in Active Directory for your primary site server is the account which needs to have at least Read rights to the remote network share, and read NTFS rights to the files/folders on that share.
That's all for now, more tips and tricks later?!
Labels:
ConfigMgr,
Deployment,
Tips,
Tricks,
Troubleshooting
Wednesday, February 9, 2011
Handy tips and tricks for ConfigMgr deployment
For multiple years I am busy now with (client) deployment, delivering applications, configuring policies, and a lot of troubleshooting. This with many products, on both fysical and virtual systems. For example:
Here they are (most of them i've seen during the last few months):
That's all for now, more tips and tricks later?!
- System Center tools: Configuration Manager (SMS, SCCM), Operations Manager (MOM, SCOM), Essentials, Updates Publisher (SCUP), Server Updates Services (WSUS)
- Deployment tools: Ghost Server, Deployment Services (WDS), Deployment Toolkit (MDT) Configuration Manager (SMS, SCCM), Altiris Server, Wyse Device Manager (WDM)
- Knowledge of: Desktop Optimization Pack (MDOP), VMware View (VDI), RES PowerFuse, RES Wisdom, Group Policy Objects (GPO), Group Policy Preferences (GPP)
Here they are (most of them i've seen during the last few months):
- When deploying a device multiple times during a "capture and deploy" Task Sequence, and a abortpxe.com error message is displayed, delete the obsolete object in the specific collection, and add the new object again. Most of times there will be two objects with the same name. (where one will be obsolete)
- When deploying a device multiple times, and startover again within 15 minutes, there will be a error message displayed. This is default WDS (Windows Deployment Services) behaviour, and can be solved with restarting the WDS service.
- When creating a new Windows image from source files, put the auto-apply drivers or apply driver package step before the "Apply Operating System" step. Otherwise specific drivers (SATA disks for example) will not be functional when booting from disk.
- When distributing a Windows image (WIM file), put the auto-apply drivers or driver package step after the "Apply Operating System" step. Otherwise an error will follow, and Task Sequence fails.
- When using multiple driver packages for one single Windows image, put a WMI query on it. With the query SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "%<MODEL>%" you can decide which driver package belongs to which system.
- When drivers or driver packages are not installed during deployment, add an extra line in sysprep.inf which contains "UpdateInstalledDrivers=Yes" to make it work again (Windows XP solution).
- When putting Software Updates in the Task Sequence, and the system is not yet domain member, add the next lines to the "Setup windows and ConfigMgr" step (SMSSLP=SERVERNAME.FQDN.COM SMSMP=SERVERNAME.FQDN.COM)
- When Software Updates are not installed during the Task Sequence, change the advertisement at Download Settings > Slow network boundary from "Do not install updates" to "Download software updates from distribution point and install".
- When build and capture Windows 7 in ConfigMgr, don't add a product key in the Task Sequence (Apply OS step). Otherwise it fails with error 8004005 and exit code 31. This because the product key and product will not match then!
- When access to a remote share (distribution point) is not working, then additional rights are needed. The server which is your Primary site server is the one which needs to go to the source folder. This account needs to have at least Read rights to the network share, and read NTFS rights to the files/folders on that share.
- When a "PXE-E32: TFTP open timeout" error message is displayed during PXE network boot, import the device manually in ConfigMgr, or activate "Unknown computer support" feature.
- When "Program Files cannot be located on a Distribution point" error message is displayed during loading the boot image, select "When no local distribution point is available, use a remote distribution point" in the advertisement.
That's all for now, more tips and tricks later?!
Labels:
ConfigMgr,
Deployment,
Tips,
Tricks,
Troubleshooting
Friday, January 14, 2011
Configure dynamic collections in ConfigMgr
After the success of my first blog "Creating dynamic collections in ConfigMgr" (most pageviews on this blog), I will write a follow-up on this item. It seems that many people are searching on this specific item, because there are no dymanic collections based on AD discovery data when installing ConfigMgr 2007. In this blog I will describe exactly what to do for having dynamic configuration. It must work this way!
First create new collections for all places there are systems in Active Directory OU's. When you have different OU's for desktops, laptops & specials for meaning, create collections for that systems also. It is also possible to bound user groups to it, which are useful for application deployment. I will write a new blog for App-V packages in ConfigMgr 2007 later on. On all of the collections you have the choice to configure systems or users/user groups.
I have created an "Virtual Machines" OU first. Now start a "Active Directory System Group Discovery". This can be found at Site Management > Site Server > Site Settings > Discovery Methods. This System Group Discovery must have the following settings: "Enable Active Directory System Group Discovery".
Give the query a name (in my case Virtual Machines) and choose for "Edit Query Statement". Let the option "Collection limiting" at default (Not collection limited), because when choosing "Limit to collection" not all the systems can be found.
When select OK a new windows will be opened. On the tab "Criteria" select the yellow star, and choose Select again (beneath "Simple value"). Choose here for the following options:
Fill in "System Resource" and "System OU Name" and select OK. In the next field choose Value (beneath "is equal to"). This will open a new window, with OU's recognized before (Active Directory System Group Discovery).
First create new collections for all places there are systems in Active Directory OU's. When you have different OU's for desktops, laptops & specials for meaning, create collections for that systems also. It is also possible to bound user groups to it, which are useful for application deployment. I will write a new blog for App-V packages in ConfigMgr 2007 later on. On all of the collections you have the choice to configure systems or users/user groups.
I have created an "Virtual Machines" OU first. Now start a "Active Directory System Group Discovery". This can be found at Site Management > Site Server > Site Settings > Discovery Methods. This System Group Discovery must have the following settings: "Enable Active Directory System Group Discovery".
Choose the yellow star, and add the domain you are working with. In my case this is SystemCenter.com. First choose for the default AD settings: Local domain and Recursive will be default selected. It is also possible for selecting an specific OU, instead of complete discovery (see options below).
- Local domain: Browse for AD containers in the domain where the computer running the Configuration Manager 2007 console resides.
- Custom LDAP: Indicates that you want to browse for Active Directory containers. This option activates Browse.
- Recursive: Default. When selected, indicates that AD discovery searches child containers. Otherwise, child containers are not searched.
- Include groups: Not default. When selected, Active Directory discovery discovers objects within groups.
When choosing for Local domain (default option), the above screenshot will be displayed. Choose the Domainname for searching in all containers. The OU's with systems in it will be automatically recognized. (It is also possible for selecting an specific OU, instead of complete discovery).
On the tab "Polling Schedule" you can change the schedule option from 1 day to 1 hour or lower (best practice when using ConfigMgr 2007 R2). This because otherwise new Active Directory OU's will be synchronized once a day. With ConfigMgr 2007 R3 this is not needed anymore, so it doesn't have to be changed.
New in ConfigMgr 2007 R3 is "Enable delta discovery" which is default set on 5 minutes. This setting doesn't have to be changed, because this performs an intermediate discovery cycle adding only new resources to the ConfigMgr database. Choose also "Run full discovery as soon as possible" for recognizing Active Directory OU's immediately.
On the tab "Membership Rules" you can change the schedule option from 1 day to 1 hour or lower (best practice when using ConfigMgr 2007 R2). This because otherwise new systems will be synchronized to collections once a day. With ConfigMgr 2007 R3 this is not needed anymore, so it doesn't have to be changed.
New in ConfigMgr 2007 R3 is "Dynamically add new resources" which is default off. Choose to turn it on, because this allows you to more rapidly evaluate a collection membership by adding only newly discovered resources. Now open collection properties (in my case Virtual Machines), and click on the yellow (database) icon.
When select OK a new windows will be opened. On the tab "Criteria" select the yellow star, and choose Select again (beneath "Simple value"). Choose here for the following options:
Fill in "System Resource" and "System OU Name" and select OK. In the next field choose Value (beneath "is equal to"). This will open a new window, with OU's recognized before (Active Directory System Group Discovery).
As you can see only 2 options are available. This because these are the only containers which contains systems. I choose "Virtual Machines" here, and select OK again. My Criterion properties has the following information now:
Choose OK multiple times now, and the configurating will be done. Now there is a new collection created, which is synchonizing from a Active Directory OU. When I choose Refresh, the systems in Active Directory will be automatically displayed in the "Virtual Machines" collection.
I hope you have enough information now for setting up a dynamic collection. When there are questions or other input, please add a comment to this blog, or contact me by e-mail.
Labels:
Collections,
ConfigMgr,
Configuration Manager,
R3,
SCCM,
System Center
Tuesday, January 4, 2011
Task Sequence fails after R3 Client Hotfix
When installing Configuration Manager 2007 with the Release 3 (R3) update, there must be a Client Hotfix installed first. This hotfix (KB977384) will create a package and program for you, which is handy for updating existing clients. Download location: http://support.microsoft.com/kb/977384
When advertising this client hotfix to systems only it will works fine, but when adding this client hotfix to a Task Sequence for deploying multiple applications it goes wrong. The Task Sequence will simply fails after installing the client hotfix, and installation will stop working.
In the SMSTS.log there will be the following errors seen:
- The sms client service is not running
- Install Software failed, hr=0x80040215
- Failed to run the action: Install <software package>
- Unknown error (Error: 80040215; Source: Unknown)
This because of the following issue:
When installing the client hotfix, it will shutdown the existing ConfigMgr client and WMI. After installation of the new client hotfix, it doesn't look like the ConfigMgr client or WMI service are restarting. Without these essential parts, installation will not working again. This is the reason why the Task Sequence will fail.
Update: Best practice from Microsoft is to not use the hotfix as single step in the task sequence. Just put it in the default "Setup windows and ConfigMgr" step. In the Installation properties box, type the following: PATCH="%_SMSTSMDataPath%\OSD\<var><Package_ID></var>\i386\hotfix\KB977384\SCCM2007AC-SP2-KB977384-x86-enu.msp"
Then installation will continue working.
When advertising this client hotfix to systems only it will works fine, but when adding this client hotfix to a Task Sequence for deploying multiple applications it goes wrong. The Task Sequence will simply fails after installing the client hotfix, and installation will stop working.
In the SMSTS.log there will be the following errors seen:
- The sms client service is not running
- Install Software failed, hr=0x80040215
- Failed to run the action: Install <software package>
- Unknown error (Error: 80040215; Source: Unknown)
This because of the following issue:
When installing the client hotfix, it will shutdown the existing ConfigMgr client and WMI. After installation of the new client hotfix, it doesn't look like the ConfigMgr client or WMI service are restarting. Without these essential parts, installation will not working again. This is the reason why the Task Sequence will fail.
Update: Best practice from Microsoft is to not use the hotfix as single step in the task sequence. Just put it in the default "Setup windows and ConfigMgr" step. In the Installation properties box, type the following: PATCH="%_SMSTSMDataPath%\OSD\<var><Package_ID></var>\i386\hotfix\KB977384\SCCM2007AC-SP2-KB977384-x86-enu.msp"
Then installation will continue working.
Labels:
Hotfix,
KB977384,
R3,
Task Sequence
Sunday, December 19, 2010
ConfigMgr 2007 with App-V integration
With ConfigMgr 2007 Release 2 (R2) it is possible to add App-V packages to the ConfigMgr console, and advertise them to ConfigMgr clients. With that functionality, no additional App-V Management or Streaming server is needed anymore. Now there is one solution for managing and publishing MSI-based & Virtual-based applications! I will explain in this blog what to configure in the ConfigMgr console, and how the App-V packages will be published to the ConfigMgr clients.
How it works?
ConfigMgr 2007 supports running sequenced applications created using the App-V Platform. App-V packages are running on ConfigMgr 2007 clients without having to install applications on the computer. Target computers must be running Windows XP (or above) to run virtual application packages. After you create a sequenced application using the App-V Sequencer, you must import the package into ConfigMgr 2007 and deploy the App-V package to ConfigMgr 2007 clients.
First you must make sure you are running ConfigMgr SP2 and R2 or R3 for having fast App-V package delivery. While Release 2 (R2) is needed for App-V functionality, Service Pack 2 (SP2) is needed for fast App-V package delivery. Because with ConfigMgr SP1 it could take up to 10 - 15 minutes for having the App-V packages available, while with SP2 there is almost no delivery delay! With ConfigMgr SP2, delivery can be as fast as with App-V streaming server, which is a great feature!
Client setup
On the computer there is a ConfigMgr client and a App-V client needed. There is no additional configuration on the App-V client needed. You need to enable Virtual Application Deployment in ConfigMgr, and ConfigMgr configures the App-V client for you. Any existing policies will be overruled. Best practice is to put the ConfigMgr client and App-V client in the Task sequence, which is used at deployment. Otherwise App-V delivery is not possible.
ConfigMgr 2007 setup
I will describe here which configuration is needed in the ConfigMgr console. These are all needed for having App-V functionality in ConfigMgr 2007.
Warning: this approach will affect every App-V client with the ConfigMgr client connected to the site. This because App-V management in ConfigMgr will overrule the existing App-V configuration.
Because ConfigMgr supports two types of App-V delivery (streaming and local delivery), you need the above setting. Streaming delivery is simular to App-V streaming server and uses HTTP(S). Local delivery does "download and execute" the App-V package using BITS (same as MSI-based applications). With local delivery the App-V package will be saved on the computer, and is alltimes available (same as MSI-based (installed) applications)! Streaming is recommended on (VDI) desktops or fat clients.
How it works?
ConfigMgr 2007 supports running sequenced applications created using the App-V Platform. App-V packages are running on ConfigMgr 2007 clients without having to install applications on the computer. Target computers must be running Windows XP (or above) to run virtual application packages. After you create a sequenced application using the App-V Sequencer, you must import the package into ConfigMgr 2007 and deploy the App-V package to ConfigMgr 2007 clients.
First you must make sure you are running ConfigMgr SP2 and R2 or R3 for having fast App-V package delivery. While Release 2 (R2) is needed for App-V functionality, Service Pack 2 (SP2) is needed for fast App-V package delivery. Because with ConfigMgr SP1 it could take up to 10 - 15 minutes for having the App-V packages available, while with SP2 there is almost no delivery delay! With ConfigMgr SP2, delivery can be as fast as with App-V streaming server, which is a great feature!
Client setup
On the computer there is a ConfigMgr client and a App-V client needed. There is no additional configuration on the App-V client needed. You need to enable Virtual Application Deployment in ConfigMgr, and ConfigMgr configures the App-V client for you. Any existing policies will be overruled. Best practice is to put the ConfigMgr client and App-V client in the Task sequence, which is used at deployment. Otherwise App-V delivery is not possible.
ConfigMgr 2007 setup
I will describe here which configuration is needed in the ConfigMgr console. These are all needed for having App-V functionality in ConfigMgr 2007.
Warning: this approach will affect every App-V client with the ConfigMgr client connected to the site. This because App-V management in ConfigMgr will overrule the existing App-V configuration.
In the ConfigMgr Distribution point properties (General) choose for "Allow clients to transfer content from this Distribution point using BITS, HTTP, and HTTPS"
In the ConfigMgr Distribution point properties (Virtuall Applications) choose for "Enable virtual application streaming"
At last, in the Advertised Programs Client Agent properties (General) enable "Allow virtual application package advertisement"
Because ConfigMgr supports two types of App-V delivery (streaming and local delivery), you need the above setting. Streaming delivery is simular to App-V streaming server and uses HTTP(S). Local delivery does "download and execute" the App-V package using BITS (same as MSI-based applications). With local delivery the App-V package will be saved on the computer, and is alltimes available (same as MSI-based (installed) applications)! Streaming is recommended on (VDI) desktops or fat clients.
App-V packages
In the ConfigMgr console you can add MSI-based & Virtual-based applications. I will describe the steps for adding App-V packages here.
Right-click on Software Distribution - Packages and choose for New > Virtual Application Package. Find the XML file, and add the App-V package.
Create an (sub)Collection for every application you want to advertise. Create a Active Directory group for every application, and add it to the collection.
Create an advertisement for every application you want to distribute, and add it to the collection with the same name. Choose for the following settings:
- Schedule: Mandatory assignments (occurs on current date/time)
- Distributing points: Stream virtual applications from Distribution point
- Interaction: Allow users to run the program independently of assignments
While sequencing choose for leaving icons in the Start menu and/or on the Desktop. This because no App-V Publishing server will be available, and users will see no icons to start the application.
Results on the computer
When all of the above steps has been set, App-V delivery will be available. On the ConfigMgr client there will be a policy refresh everytime you logon. At that point the App-V package will be available after 5 - 30 seconds. This will depends on sizing and configuration of the ConfigMgr server.
Again more functionality becomes available in the ConfigMgr console!
Again more functionality becomes available in the ConfigMgr console!
Saturday, December 11, 2010
MDT integration in ConfigMgr 2007
Last month I read at Twitter that someone didn't know that MDT could be integrated with ConfigMgr 2007. For me that was the reason for writing this blog about MDT and ConfigMgr. Yes, it's true that the intregation exists, and I will explain all the possibilities and benefits of it! When you are new with MDT or ConfigMgr, you can combine them for having the best of both worlds. Also with the knowledge you have (MDT and/or ConfigMgr) it will be a lot easier for using it.
When you using Microsoft products for deployment, you can choose between:
- Windows Deployment Services (WDS)
- Microsoft Deployment Toolkit (MDT)
formely known as Business Desktop Deployment (BDD)
- System Center Configuration Manager (ConfigMgr)
While WDS and MDT are free of use; with ConfigMgr you must pay for every system you want to manage (client and/or server). In the projects I do, the choice is most of times made for ConfigMgr. This because ConfigMgr can do a lot more then MDT; and MDT will most of times be implemented for deployment only. Because MDT is customizable with build-in scripts, you want the same functionality in ConfigMgr actually! For this reason Microsoft created the integration for both products.
For having this functionality, install ConfigMgr and MDT (2010) on the same system. After that look in the Start Menu for Microsoft Deployment Toolkit, and start "Configure ConfigMgr Integration". Click Next, Finish, and start the ConfigMgr console again! Now you will have the following added features.
New Task sequences added:
The new Task sequences offers very useful deployment templates that are constructed using a new MDT wizard.
New options in existing Task sequences:
The new options offers additional environmental checks and data. This provides for prerequisite and safety checks before applying the image, and additional environment variables for use in customization.
Create new Boot images:
This provides the ability to build customized Windows PE boot images, through a wizard added to the boot images menu item.
At last you can use the build-in scripts that's included with MDT, for using in ConfigMgr 2007 Task sequences. With MDT integration in ConfigMgr 2007 you have the best of both worlds. And with new functionality in MDT 2010 Update 1 there is even more available! (User Driven Installation)
MDT 2010 can be used for Lite Touch Installation (LTI):
- Aligns with ConfigMgr
- Evolutionary refinements
- Adds server support
- Upgrade from BDD 2007 and MDT 2008
ConfigMgr 2007 (with MDT) is needed for Zero Touch Installation (ZTI):
- Fully integrated experience
- Single console
- Adds server support
- Extends and enhances ConfigMgr 2007
You can even have a dynamic computername filled-in, and place it in Active Directory in the right OU. In the customsettings.ini file (MDT) or Task sequence (set Task sequence variable) there must be an entry that looks like this:
When you using Microsoft products for deployment, you can choose between:
- Windows Deployment Services (WDS)
- Microsoft Deployment Toolkit (MDT)
formely known as Business Desktop Deployment (BDD)
- System Center Configuration Manager (ConfigMgr)
While WDS and MDT are free of use; with ConfigMgr you must pay for every system you want to manage (client and/or server). In the projects I do, the choice is most of times made for ConfigMgr. This because ConfigMgr can do a lot more then MDT; and MDT will most of times be implemented for deployment only. Because MDT is customizable with build-in scripts, you want the same functionality in ConfigMgr actually! For this reason Microsoft created the integration for both products.
For having this functionality, install ConfigMgr and MDT (2010) on the same system. After that look in the Start Menu for Microsoft Deployment Toolkit, and start "Configure ConfigMgr Integration". Click Next, Finish, and start the ConfigMgr console again! Now you will have the following added features.
New Task sequences added:
The new Task sequences offers very useful deployment templates that are constructed using a new MDT wizard.
- Client Task Sequence: Creates a complete task sequence complete with additional task sequence elements.
- Client Replace Task Sequence: Creates a task sequence specifically for use when replacing hardware (capture user state).
- OEM Task Sequences (Pre- and Post-OEM): Creates task sequences specifically designed for use with the hardware OEM.
- Microsoft Deployment Custom Task Sequence: Creates a task sequence that is essentially empty.
- Server Task Sequence: The server version of the Client Task Sequence with additional task sequence elements.
- User Driven Installation Task Sequence: UDI means that there is now an easy way to get users “involved” in an OS Deployment.
New options in existing Task sequences:
The new options offers additional environmental checks and data. This provides for prerequisite and safety checks before applying the image, and additional environment variables for use in customization.
- Use Toolkit Package: Takes care of getting the needed files to the computer (needed to use any other actions)
- Install Language Packs Online: Specify that package should be installed online (after the OS is running)
- Gather: Sets variables that can be used elsewhere in the task sequence (needed for dynamic deployments)
- Validate: Perform hardware checks to make sure the machine is capable, and prevent accidental deployment of client operating systems to server hardware
- Install Roles and Features: Install any available Windows Server 2008 (R2) role, role service, or feature
- Configure ADDS: Automates the DCPROMO process, and supports creating new forests, new domains, and new domain controllers
- Configure DNS: Define the zones that need to be created (Primary, secondary, stub, Integrated or standard)
- Configure DHCP: Define the scopes that need to be created (Address ranges, scope settings)
- Install Updates Offline: Apply patches to Windows before the OS boots for the first time (uses an existing software update package)
- Install Language Packs Offline: Specify that package should be installed offline (before the OS boots for the first time, similar to patching)
Create new Boot images:
This provides the ability to build customized Windows PE boot images, through a wizard added to the boot images menu item.
- Add extra folders and files to the boot image (example: Trace32 utility)
- Add support for additional databases in the boot image
At last you can use the build-in scripts that's included with MDT, for using in ConfigMgr 2007 Task sequences. With MDT integration in ConfigMgr 2007 you have the best of both worlds. And with new functionality in MDT 2010 Update 1 there is even more available! (User Driven Installation)
MDT 2010 can be used for Lite Touch Installation (LTI):
- Aligns with ConfigMgr
- Evolutionary refinements
- Adds server support
- Upgrade from BDD 2007 and MDT 2008
ConfigMgr 2007 (with MDT) is needed for Zero Touch Installation (ZTI):
- Fully integrated experience
- Single console
- Adds server support
- Extends and enhances ConfigMgr 2007
You can even have a dynamic computername filled-in, and place it in Active Directory in the right OU. In the customsettings.ini file (MDT) or Task sequence (set Task sequence variable) there must be an entry that looks like this:
- OSDComputerName=%SERIALNUMBER% to use SERIALNUMBER as computername
- OSDComputerName=%ASSETTAG% to use ASSETTAG as computername
It is also possible to use a script for it. With all of this you can have a dynamic deployment, without the need for manually actions!
Labels:
Configuration Manager,
MDT 2010,
SCCM 2007
Tuesday, November 30, 2010
Best Practice in Group Policy Management
When using Group Policy Objects (GPO), what is the best practice for using it? I come many times at customers with a lot of policies, and most of the times people don't know what to do with it. This because new settings are needed, and everytime there will be a new policy created. When this proces goes on for years, nobody knows the reason for all these policies anymore. But what's the best practice for using it then? I will explain that, and also talk about other products for managing policies!
Group policies are exists a long time now. First there were the local policies, then group policies became available. It became even better when the Group Policy Management Console (GPMC) was available. Now there was truly management of all the policies. Today there is also an extension available. When using Group Policy Preferences (GPP) there will be also new Windows and Control Panel settings available to manage. With that the need of a login script isn't necessary anymore. And the good news is, it's free of use!
Best Practices of Group policies are:
- Don't create a new policy for every new setting you want to use (only for testing purposes)
- Minimize the number of policies, for faster logons (less files) and easy management
- Create a user policy and disable the computer part of it (screenshot)
- Create a computer policy and disable the user part of it (screenshot)
- For policies with an extra ADM file (imported in Administrative templates), create a separate policy for easy management (screenshot)
- When putting user settings on computer objects, use Loopback processing mode with the merge or replace option (screenshot)
How to disable user or computer policy settings (2 ways):
Usage of User Group Policy loopback processing mode:
This setting directs the system to apply the set of Group Policy objects for the computer to any user who logs on to a computer affected by this setting. By default, the user's Group Policy objects determine which user settings apply. If this setting is enabled, then, when a user logs on to this computer, the computer's Group Policy objects determine which set of Group Policy objects applies.
To use this setting, select one of the following modes from the Mode box:
Download Group Policy Management Console (GPMC):
The Group Policy Management Console is the easiest way for managing Group Policies. For using it there are different ways to follow:
This extension of Group Policy Objects (GPO) allows the use of a logon script is less applicable. Default settings like Drive Mappings, Printers, Start Menu items and Shortcuts can now be assigned with Preferences, allowing the establishment as a whole it looks easier. The configuration of Group Policy Preferences is as follows. When opening the Group Policy Management Console on a Windows 2008 server, not just the policies are shown, but also the preferences will be shown.
Here you will have the choice for configuring all new Windows and Control Panel settings available. With the Targeting Editor you can even control on which condition the new Preferences will be become active. There are many types of Targeting possible, example: Computer Name, IP Address Range, Organizational Unit, Security Group or WMI Query.
Best practice for these are creating new GPO's and placing the Preferences settings in that. All you need is a Windows Server 2008 (R2) or Windows 7 or Vista for managing the preferences. You don't need a Windows 2008 domain level for Preferences!
For more information about Preferences, download the following white paper: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=42E30E3F-6F01-4610-9D6E-F6E0FB7A0790
Managing GPO's with Advanced Group Policy Management:
Microsoft Advanced Group Policy Management (AGPM) is a component of the Microsoft Desktop Optimization Pack (MDOP). AGPM increases the capabilities of the Group Policy Management Console (GPMC), providing:
- Standard roles for delegating permissions to manage GPO's to multiple Group Policy administrators.
- An archive to enable Group Policy administrators to create and modify GPO's offline before deploying them to a production environment.
- The ability to roll back to any previous version of a GPO.
- Check-in/check-out capability for GPO's to ensure that Group Policy administrators do not overwrite each other's work.
Some features include:
I hope you have enough information about Group Policy Management by now! Check my blog regular for more information about GPO's.
And remember: Always create a back-up when deleting GPO's! When restoring them settings and rights will be restored again.
Group policies are exists a long time now. First there were the local policies, then group policies became available. It became even better when the Group Policy Management Console (GPMC) was available. Now there was truly management of all the policies. Today there is also an extension available. When using Group Policy Preferences (GPP) there will be also new Windows and Control Panel settings available to manage. With that the need of a login script isn't necessary anymore. And the good news is, it's free of use!
Best Practices of Group policies are:
- Don't create a new policy for every new setting you want to use (only for testing purposes)
- Minimize the number of policies, for faster logons (less files) and easy management
- Create a user policy and disable the computer part of it (screenshot)
- Create a computer policy and disable the user part of it (screenshot)
- For policies with an extra ADM file (imported in Administrative templates), create a separate policy for easy management (screenshot)
- When putting user settings on computer objects, use Loopback processing mode with the merge or replace option (screenshot)
How to disable user or computer policy settings (2 ways):
- Right-click the name of the GPO, and click Properties. Click Disable Computer Configuration settings or Disable User Configuration settings.
- Right-click the name of the GPO, and click GPO Status. Click Disable Computer Configuration settings or Disable User Configuration settings.
Import a ADM file in Administrative Templates:
- Right-click on Administrative Templates in the GPO, and choose for Add/Remove Templates.
- Click Add and search for the ADM file to import. (this file will be copied to the Sysvol folder after that)
This setting directs the system to apply the set of Group Policy objects for the computer to any user who logs on to a computer affected by this setting. By default, the user's Group Policy objects determine which user settings apply. If this setting is enabled, then, when a user logs on to this computer, the computer's Group Policy objects determine which set of Group Policy objects applies.
To use this setting, select one of the following modes from the Mode box:
- "Replace" indicates that the user settings defined in the computer's Group Policy objects replace the user settings normally applied to the user.
- "Merge" indicates that the user settings defined in the computer's Group Policy objects and the user settings normally applied to the user are combined. If the settings conflict, the user settings in the computer's Group Policy objects take precedence over the user's normal settings.
Download Group Policy Management Console (GPMC):
The Group Policy Management Console is the easiest way for managing Group Policies. For using it there are different ways to follow:
- For Windows Server 2003 (and Windows XP) you must download and install it from the following URL: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=0a6d4c24-8cbd-4b35-9272-dd3cbfc81887&displaylang=en
- For Windows Server 2008 you need to add it manually using the Server Manager: Add Features. After that GPMC has been installed, and you can find it as normal in the Administrative Tools.
- For Windows 7 you must download the Remote Server Administration Tools (RSAT) from the following URL and install it: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=7d2f6ad7-656b-4313-a005-4e344e43997d&displayLang=en
After that GPMC has been installed, and you can find it as normal in the Administrative Tools.
This extension of Group Policy Objects (GPO) allows the use of a logon script is less applicable. Default settings like Drive Mappings, Printers, Start Menu items and Shortcuts can now be assigned with Preferences, allowing the establishment as a whole it looks easier. The configuration of Group Policy Preferences is as follows. When opening the Group Policy Management Console on a Windows 2008 server, not just the policies are shown, but also the preferences will be shown.
Best practice for these are creating new GPO's and placing the Preferences settings in that. All you need is a Windows Server 2008 (R2) or Windows 7 or Vista for managing the preferences. You don't need a Windows 2008 domain level for Preferences!
For more information about Preferences, download the following white paper: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=42E30E3F-6F01-4610-9D6E-F6E0FB7A0790
Managing GPO's with Advanced Group Policy Management:
Microsoft Advanced Group Policy Management (AGPM) is a component of the Microsoft Desktop Optimization Pack (MDOP). AGPM increases the capabilities of the Group Policy Management Console (GPMC), providing:
- Standard roles for delegating permissions to manage GPO's to multiple Group Policy administrators.
- An archive to enable Group Policy administrators to create and modify GPO's offline before deploying them to a production environment.
- The ability to roll back to any previous version of a GPO.
- Check-in/check-out capability for GPO's to ensure that Group Policy administrators do not overwrite each other's work.
Some features include:
- Offline editing of GPO's
- Difference reporting and audit logging
- Recovery of a deleted GPO (Recycle Bin) <- Nice feature!
- Repair of live GPO's
- Creation of GPO template libraries
- Subscription to policy change e-mail notifications
- Version tracking, history capture, and quick rollback of deployed changes
- Role-based administration (Editor, Reviewer, Approver)
- Change request approval
I hope you have enough information about Group Policy Management by now! Check my blog regular for more information about GPO's.
And remember: Always create a back-up when deleting GPO's! When restoring them settings and rights will be restored again.
Labels:
AGPM,
Best Practice,
GPO,
GPP,
Group Policy,
Policies
Wednesday, November 17, 2010
Useful Information from TechEd 2010 Berlin
Last week I was at TechEd 2010 in Berlin. With 6,000 delegates the event was sold out! It was a nice week with lots of useful information about Management and Windows Client (my favourite tracks). There were many companies with further additions for ConfigMgr (software catalog, mobile devices, self service portal, etc.). The sessions I've done are about the following products:
Useful information about Configuration Manager:
Useful information about Group Policy (Preferences):
Useful information about other deployment tools:
Handy URL's for best practice in deployments are:
Next year on TechEd 2011 and MMS 2011/2012 there will be more information about ConfigMgr 2012, and all new functionality in it!
- Deployment (best practices, issues, etc.)
- ConfigMgr 2007 and v.Next (2012)
- MDOP (Advanced Group Policy Management 4.0)
- Migrate Windows XP to Windows 7
- Windows Embedded (WES2009 and WES7)
- MS Deployment Toolkit (MDT) 2010
- Forefront Endpoint Protection (FEP) 2010
- Group Policy Objects (and Preferences)
- MS Enterprise Desktop Virtualization (Med-V) v2
- The name for the next release of ConfigMgr, will be System Center Configuration Manager 2012. The 2012 release will be User Centric instead of Device Centric. The product is currently in Beta 1; Beta 2 is expected to be released around H1 2011.
- New for the user in ConfigMgr 2012 is, the Software Catalog portal on the workplace. With the Software Catalog portal you can easily search for new software and install (or request) the software on your computer.
- There will be more support for mobile devices in ConfigMgr 2012. Not only support for Windows Mobile 6.x, but also for Android 2.2.2, iOS 4.0, Symbian 3.3.3 and Windows Phone 7. Maybe more to come!?
- You can deploy WES2009 and WES7 in WDS, MDT 2010 and ConfigMgr 2007 on Embedded devices. With ConfigMgr 2007 there is also support for using Task Sequences.
- Forefront Endpoint Protection (FEP) 2010 will be fully integrated with ConfigMgr 2012. You only need one console to manage your clients!
- Choose which installation you want on different kind of devices in ConfigMgr 2012 (e.g. MSI-based on fat clients and App-V packages on Tablet devices. (works great!)
- In ConfigMgr 2012 there is Delegation of control by default. No need for selecting functionalities by yourself! Also the ConfigMgr console shows only the information which you may see, so it's custom by default!
- There is an Hotfix available for solving duplicate drivers issues in ConfigMgr 2007: (no more troubleshooting on driver packages)! http://support.microsoft.com/kb/2213600
- There is an Exchange Server connector build in ConfigMgr 2012 for managing Windows Phone 7 devices! Maybe more to come!?
- With Collection membership rules, you can put subcollections in other collections for managing deployments and distributions.
- You can set overall ConfigMgr client settings, for pushing new settings to all clients at once! (handle with care)
- With Med-V v2 there will be ConfigMgr integration! It will be fully manageable with ConfigMgr, which will simplify overhead and management for IT professionals.
Useful information about Group Policy (Preferences):
- With Advanced Group Policy Management 4.0 you can compare settings between GPO's. Also Delegation of control is possible (decide which GPO's you may see or change). And there is an History function in it, so you can go back to older versions of a GPO.
- Another nice thing in Advanced Group Policy Management 4.0 is the Recycle bin, where all deleted GPO's will be saved for some time. Because everything will be tracked in the program, it's easy to see which administrator has done some changes in it.
- New in version 4.0 is the search option (for searching GPO's, not in GPO's) and multiforest support. There is also support for Preferences and AppLocker!
- When troubleshooting Group Policies, search for the userenv.log (for errors) on Windows XP or the GPO log (Event Viewer) on Windows 7.
- There is a nice tool for troubleshooting Windows Vista & 7, called Group Policy Log View. http://www.microsoft.com/downloads/en/details.aspx?FamilyID=BCFB1955-CA1D-4F00-9CFF-6F541BAD4563&%3Bdisplaylang=en
- Look on Jeremy Moskowitz site for more info:
- http://www.gpanswer.com/ (Group Policy Community)
- http://www.policypak.com/ (PolicyPak Software)
Useful information about other deployment tools:
- You can use the install.wim for Windows 7 deployment (with Vista that didn't work, it will be installed on the D: drive)
- Use Windows Automated Installation Kit (AIK) 2.0 for deploying Windows 7 with ConfigMgr: http://www.microsoft.com/downloads/en/details.aspx?familyid=696DD665-9F76-4177-A811-39C26D3B3B34&displaylang=en
- When using WDS make sure you use the Server 2008 version (multicast support, Server Message Block (SMB) 2.x for faster deployments, driver management)
- With MDT 2010 you have light touch deployment functionality, but ConfigMgr stays needed for zero touch deployment!
- In ConfigMgr you can press F8 for command support (e.g. troubleshooting). In MDT 2010 you can press SHIFT + F10 for the same functionality!
- WES2009 and WES7 can be deployed with either CD/USB media, PXE boot, boot from VHD, WDS/MDT 2010 and ConfigMgr 2007 (with some kind of customization) <- I will blog on that later
- Use the MS Assessment and Planning (MAP) Toolkit 5.0 for inventory, assessment and reporting for assess IT environments: http://technet.microsoft.com/en-us/solutionaccelerators/dd537566.aspx
- Use the MS Application Compability Toolkit (ACT) 5.6 for Windows 7 application support: (very handy!) http://www.microsoft.com/downloads/en/details.aspx?FamilyId=24DA89E9-B581-47B0-B45E-492DD6DA2971&displaylang=en
- When searching for all kind of drivers, use the Microsoft Update Catalog! (choose for search on name or also GUID from driver) http://catalog.update.microsoft.com/v7/site/Home.aspx
- With Med-V v2 you can access Windows XP apps within Windows 7 (Windows XP mode). There will be seamless integration for both Windows XP and Windows 7 in the same start menu. (very nice!)
Handy URL's for best practice in deployments are:
- www.deploymentcd.com (Johan Arwidmark & Mikael Nystrom)
- www.deployvista.com (Johan Arwidmark)
- www.deploymentdr.com (Rhonda Layfield)
Next year on TechEd 2011 and MMS 2011/2012 there will be more information about ConfigMgr 2012, and all new functionality in it!
Wednesday, November 3, 2010
Using Multicast functionality in ConfigMgr
By default ConfigMgr 2007 Operating System Deployment (OSD) is deploying in Unicast. Every deployment or software distribution will be bit by bit transferred to the device. With ConfigMgr 2007 R2, and specific configuration, Multicast is also possible. Then you can deploy maybe 50 or 100 devices at a time, without the data (bits) being transferred to every device for itself. It's good to know that you have a few possibilities in Multicast, and it's only working in WinPE mode. So what's the advantage of it, with Software distribution in the Task Sequences?
When you talk about Multicast in ConfigMgr R2, there are two types of it. There is a Autocast and Scheduled Multicast possibility. I will describe them both, and explain the differences between them.
Autocast: With Autocast the deployment will start on the first device. When you deploy another device (or more than one) the stream will also be transferred to the other device(s). When the first one is finished, the other device(s) must only pick the other bits for completion. The only thing you have to do for Autocast functionality, is enable Multicast. (screenshot)
Scheduled Multicast: With Scheduled Multicast the deployment will wait for a few minutes or number of clients. The deployment will then start when one of the two conditions are met. The idea behind this, that you have more time to prepare your devices. With this type of deployment the bitstream wil go once over the network, to all your machines that are ready! (screenshot)
For Multicast to get it working, there is a Distribution Point and the Transport server in Windows Deployment Services (WDS) needed. When both are installed and enabled on a Windows 2008 Server, the configuration in ConfigMgr 2007 will take place.
Distribution point: In the ConfigMgr Distribution Point properties you must enable the setting "Allow clients to transfer content from the distribution point using BITS, HTTP and HTTPS". Also on the Multicast tab you must enable the "Enable multicast" setting. Have also a look on the Transfer rate possibility. Ideally this must be set to 100 Mbps or 1 Gbps for a good transfer speed.
When you also want to make use of Scheduled Multicast, you must enable the setting "Enable scheduled multicast" and set the Session start delay (# minutes) and the Minimum session size (# clients). When one of two are met, the deployment will be started (one bitstream).
Image deployment: When you want a succesfull Multicast deployment, the default WIM image must also be Multicast enabled. Open the properties of the WIM image (example: Windows XP SP2), and enable the setting "Allow this package to be transferred via multicast". You can also see here that Multicast functionality is only possible with WinPE (so during the first part of deployment).
When you don't want any Unicast deployment, enable also the setting "Transfer this package only via multicast". Then you are sure that Multicast will be used! Because this will only works in WinPE, there isn't any need to enable this setting on your Software packages. Now there only must be set an advertisement to get it work.
Advertisement: In the advertisement enable the setting "Download content locally when needed by running task sequence". When this is set on: "Access content directly from a distribution point when needed by the running task sequence", Multicast deployment will not work.
Deployment: These are some pictures displayed during deployment. The first one is captured during deployment in Autocast; the second one is captured during Scheduled Multicast.
Because Multicast works only in WinPE mode, you have the choice to put your applications in the default WIM image. Not installing them, but only put the source in it. Then you are still flexible, and make use of full Multicast functionality! Otherwise a part of the installation will be in Multicast, and the other part (applications) will not.
In the Task Sequence don't add your packages with "Install Software", but choose for "Run Command Line". Then put in there the command which is normally placed in Programs - Command Line, for unattended installation. For get it working place the location (e.g. C:\Apps) before the command, and the application will be installed from the local source.
That's all about Multicast for now!
When you talk about Multicast in ConfigMgr R2, there are two types of it. There is a Autocast and Scheduled Multicast possibility. I will describe them both, and explain the differences between them.
Autocast: With Autocast the deployment will start on the first device. When you deploy another device (or more than one) the stream will also be transferred to the other device(s). When the first one is finished, the other device(s) must only pick the other bits for completion. The only thing you have to do for Autocast functionality, is enable Multicast. (screenshot)
Scheduled Multicast: With Scheduled Multicast the deployment will wait for a few minutes or number of clients. The deployment will then start when one of the two conditions are met. The idea behind this, that you have more time to prepare your devices. With this type of deployment the bitstream wil go once over the network, to all your machines that are ready! (screenshot)
For Multicast to get it working, there is a Distribution Point and the Transport server in Windows Deployment Services (WDS) needed. When both are installed and enabled on a Windows 2008 Server, the configuration in ConfigMgr 2007 will take place.
Distribution point: In the ConfigMgr Distribution Point properties you must enable the setting "Allow clients to transfer content from the distribution point using BITS, HTTP and HTTPS". Also on the Multicast tab you must enable the "Enable multicast" setting. Have also a look on the Transfer rate possibility. Ideally this must be set to 100 Mbps or 1 Gbps for a good transfer speed.
When you also want to make use of Scheduled Multicast, you must enable the setting "Enable scheduled multicast" and set the Session start delay (# minutes) and the Minimum session size (# clients). When one of two are met, the deployment will be started (one bitstream).
Image deployment: When you want a succesfull Multicast deployment, the default WIM image must also be Multicast enabled. Open the properties of the WIM image (example: Windows XP SP2), and enable the setting "Allow this package to be transferred via multicast". You can also see here that Multicast functionality is only possible with WinPE (so during the first part of deployment).
When you don't want any Unicast deployment, enable also the setting "Transfer this package only via multicast". Then you are sure that Multicast will be used! Because this will only works in WinPE, there isn't any need to enable this setting on your Software packages. Now there only must be set an advertisement to get it work.
Advertisement: In the advertisement enable the setting "Download content locally when needed by running task sequence". When this is set on: "Access content directly from a distribution point when needed by the running task sequence", Multicast deployment will not work.
Deployment: These are some pictures displayed during deployment. The first one is captured during deployment in Autocast; the second one is captured during Scheduled Multicast.
Because Multicast works only in WinPE mode, you have the choice to put your applications in the default WIM image. Not installing them, but only put the source in it. Then you are still flexible, and make use of full Multicast functionality! Otherwise a part of the installation will be in Multicast, and the other part (applications) will not.
In the Task Sequence don't add your packages with "Install Software", but choose for "Run Command Line". Then put in there the command which is normally placed in Programs - Command Line, for unattended installation. For get it working place the location (e.g. C:\Apps) before the command, and the application will be installed from the local source.
That's all about Multicast for now!
Labels:
ConfigMgr,
Configuration Manager,
Multicast,
SCCM,
System Center
Subscribe to:
Posts (Atom)