anyweb

hi are you testing with Beta 2 or Release Candidate 1 ? RC1 is the current release and i have guides for it here

yes, no problem at all to advertise several task sequences to the All Unknown Computers collection and to use them like this the error you are seeing (if it occurs during applying the wim image) is network related, is it dropping the IP address ? try a different switch/location

don't need to configure wds, are you sure you've advertised a ts to a collection that this computer is a member of ? try the unknown computers collection as well as a deploy OS collection and.. update both boot images to your dp's what is your SMSPXE.log file telling you about the problem ?

you can do it whatever works for you, you don't even have to use Update Lists unless you want to report on the deployments, this is only one way of doing it, feel free to post an alternative

if you pxe boot a client that is in the same vlan does it get the same error

can you zip up all the logs in C:\windows\ccm\logs and attach them here and i'll take a look is the application definetly on your distibutrion points ? is the configmgr client ok ?

nothing strange about them, the SCCM box has 2gb RAM, 4gb is really recommended but in a lab 2gb seems to work fine, it's got 150GB hdd partitioned as os=30gb and d=rest of drive, the AD1 server (domain controller/dhcp/dns) is 512 mb ram and 30gb hdd, anything else you want to know ? i have created separate networks so for example #5_SCCM_RC is on a virtual network spanning 192.168.5.x and #3_SCCM_RC is 192.168.3.x means i can have multiple environments which are not interfering with each other

sorry not following you KingsKawn, what's the issue exactly ?

this should give you some ideas, look at all the snapshots ! same boxes were previously beta 2

this is the reason why you should virtualise everything in your lab, that way you can restore snapshots of BEFORE you started installing Beta 2 and you have a clean slate to work with, that's the way I do it, think ahead, virtualize now - install RC in the lab, snapshot each stage of the way, then when the code goes to RTM you can restore your clean boxes and start again

choose servers and site system roles, software update point, you can configure the proxy settings in there.

you can't upgrade from beta 2 to RC, it's not supported, even if you add your sccm server name and corresponding ip address to that file you'll have SQL issues later on, start with a clean install of RC good luck

can you show the error in your log or post the log here

0ok a few years have passed (wow) and lots more members reading, using the site, i'm still looking for a News Poster (news and articles about Windows) any takers ?

how about this ? Using SCCM 2012 RC in a lab - Part 5, Enable the Endpoint Protection Role and configure Endpoint Protection settings. Part 5. Enable the Endpoint Protection Role and configure Endpoint Protection settings [November 5th 2011]

its a bug, uninstall wds, remove pxe from your dp, uninstall the dp role, reboot, add dp role, add pxe should be fine then

good question ! i've actually got two ConfigMgr 2012 RC LABS on the go at the moment, one is a standalone server used in doing these guides, and the other is a heirarchy with a CAS and Primary, here's a screenshot of my HyperV setup the RED box is the Heirarchy and the Green is the standalone what details do you want exactly ?

are you trying to install the client on production computers ? this is a Release Candidate software, not for production, you can uninstall the old sms client using ccmsetup.exe /uninstall then try again

interesting look at this that's an SMS 2003 SP3 client ! not supported, are you using SCCM 2012 RC to upgrade old clients or what ? uninstall it and try again cheers niall

well i guess i can try and repro, by keeping my clients powered off for a day or so, then sync the sccm box via internet, then power down my NAT, then power up the client.... i'll see what i can do

why are you using SCCM 2007 sp1 ? you should be using SCCM 2007 SP2 to support Windows 7 (and it's the current, supported version), as regards installing the client, you can use client push from the SCCM server as described in this guide, are you saying it's not working for you ? is the client push installation account a local administrator of your clients computer ?

hi Jeremy, I'm happy that you are trying this tool, it's really useful ! I do have an updated version of it which I havent released yet it does fix some bugs in the original tool, but to your questions... when you create an association, <u>you need to specify the destination</u> as THAT computer will be the new computer, you need to have added that computer record to Configmgr before this stage (import computer association...), understand that my tool is merely allowing you to create the association between source (the computer you've just booted into WinPE) and the Destination (new computer, previously added by you to configmgr's database). </li> all the backup (and restore) options within the task sequence are handled in different sections of the task sequence based on variables, take a look at the backupold section and later on, the restore user state, so these options you mention are set elsewhere when needed. this path is used to store our Offline data on the Network (it assumes you are doing a scanstate in WinPE and then copying this stored state to the network share..) we use this as another option to the SMP (state migration Point) sure it's possible, no problems there you can create a separate task sequence to peform scanstate on these computers and use the SMP method (state migration point) in conjunction with Computer Association yes I know the domain name throws people off and they like to make fun of it, however i'm pretty sure the same people will be browsing this site (and perhaps signing up) sooner or later, as it's got unique content displayed in a very helpful way

In Part 1 of this series we got our AD and SCCM servers ready, and then we installed System Center 2012 Configuration Manager as a standalone Primary site. In Part 2 we configured the SCCM server further by adding some Windows Server roles necessary for the following Configuration Manager 2012 functionality, Software Update Point (SUP) and Operating System Deployment. In Part 3 we configured the server further by Enabling Discovery methods and creating Boundary's and Boundary Groups. In Part 4 we configured Client Settings, Added roles and Distributed the Configmgr Client to our Computers within the LAB, then in Part 5 we enabled the Endpoint Protection Role and configured Endpoint Protection settings and targeted a collection called All Windows 7 Computers with these settings and policies. In Part 6 we configured our SUP further to Deploy software updates to our All Windows 7 Computers and Build Windows 7 X64 collections. In Part 7 we used the Build and Capture process to create our Base Windows 7 X64 wim image. In Part 8 we created a USMT 4 package to migrate the users data using hardlinking and then we imported the captured image into ConfigMgr and created a Deploy Windows 7 X64 task sequence. We created a Deploy Windows 7 X64 Collection and set some User Device Affinity collection variables. In Part 9 we created an Application, and created a deployment type for that application to only install if the Primary User was True for that device (User Device Affinity), we then copied our Task Sequence (duplicated it), deployed the new Task Sequence, added a computer to the new collection and then PXE booted the computer to the Deployment Menu. In Part 10 we monitored the Deployment process in a lot of detail to how UDA sent state messages and we verified that our application installed on the users Primary Device, in addition we modified our collection variables, and added a prestart command to our boot image to prompt for the SMSTSUdaUsers. In Part 11 we setup the Reporting Services Point Role and verified that reporting was working. Now we will use a new feature in ConfigMgr which allows us to Patch operating system WIM images using Offline Servicing. This means that you can apply Windows Updates by using Component-Based Servicing (CBS) to update the your previously captured WIM images. The Offline Servicing feature is applicable for Component Based Servicing (CBS) updates and for the following operating systems: Microsoft Windows Vista SP2 and later Microsoft Windows Server 2008 SP2 and later Microsoft Windows 7 RTM Microsoft Windows 2008 R2 DISM is used to inject the updates - Deployment Image Servicing and Management (DISM) Note: At the launch of ConfigMgr 2012 Beta 2 Microsoft Windows 7 SP1 and Windows Server 2008 R2 SP1 are not supported. They will be supported with Configuration Manager 2012 RTM. Step 1. Review our current Captured WIM file. Perform the following on your SCCM 2012 server as SMSadmin. In the ConfigMgr console, expand the Software Library and then expand Operating Systems, select Operating System Images. This will contain our previously captured Windows 7 X64 WIM image. Select our Windows 7 X64 WIM image and note the four tabs which appear. Click on the Update Status tab. This tab will list any updates that have been added to our image via Offline Servicing, we haven't completed any Offline Servicing on our WIM image yet so for this reason it will appear empty. Note: Even though our Captured image has updates installed in it already, unfortunately the Update Status tab will not list udpates that are in the captured image unless those updates that have been added via Offline Servicing after the WIM image was added to ConfigMgr. Step 2. Perform a Software Update Point Synchronization Perform the following on your SCCM 2012 server as SMSadmin. Before we perform Offline Servicing, we want to make sure we have the latest updates Synced. In Software Updates, All Software Updates. In the Ribbon, click on Synchronize Software Updates. answer Yes to the Sync request while it's syncing, using CMTrace, monitor the WsyncMgr.log file found in D:\Program Files\Microsoft Configuration Manager\Logs, look for the Sync Suceeded line to be sure it's finished. If you have synced recently it will be quick. Once the sync is complete, mark any new updates that were released since you last updated your target OS and download them and add them to your Target Operating System Software Update Group (for example, update these updates to your Windows 7 updates software update group which we created in part 6. Step 3. Start Offline Servicing Perform the following on your SCCM 2012 server as SMSadmin. Select our Captured Windows 7 X64 image and click on Schedule Updates in the ribbon The Update Operating System Image Wizard appears, note that it automatically selects the architecture of your image (X64) and you can list all the updates it has found available to this Operating System. If you want you can sort by any of the column headings, for example click on Bulletin ID to see what are the latest Bulletin ID's being made available to Offline Servicing. Note: if no updates appear, make sure to download them first. click next, and you are presented with the Set Schedule screen, this is great for ConfigMgr admins as it means you can decide when your server will do the Offline Servicing work (disk intensive) so for example you could schedule it to occur on Saturday evening when everyone is home. If you want to set a schedule click on Custom Schedule, however as we are in a LAB we will choose As soon as possible. Note: Injecting updates into the WIM images offline is disk intensive so you should not perform this operation except when the server is 'at rest'. Also allow for free space on your Configmgr Server drive as the WIM image will be duplicated (backup copy created) during this process. you'll be presented with a summary of Updates offered to the Offline Servicing Process click next to continue and review the completion screen, the wizard is quick, the injection however takes time as you will see. Step 4. Monitor the Progress with the OfflineServicingMgr.log file Perform the following on your SCCM 2012 server as SMSadmin. ConfigMgr 2012 introduced some new logs one of which is the OfflineServicingMgr.log file, open it in CMTrace so that we can monitor the progress of our Offline Servicing. You will note it mentions copying our current WIM image to a temporary folder called ConfigMgr_OfflineImageServicing, and it's at this point your ConfigMgr server will become slower to use (especially in a LAB as typically your hardware isn't that fast in a LAB and this is very disk intensive). if you browse this temp folder in Windows Explorer you can see the WIM file and some other temp folders used for the CBS injection process (via DISM) Note: make sure to close Windows Explorer or browse to a different folder than the one above as if you are browsing it during Commit, then the process will fail to delete the temp files/folders. keep watching the log in CMTrace as it will tell you what percentage is done, for example, 25% of the copying is completed once it's done copying the WIM file it mounts it to inject the CBS updates and after some time it will check all available updates to see if they are applicable or not, each update will have an Applicability State which can be listed as any of the following:- NOT_REQUIRED INSTALLED APPLICABLE APPLICABILITY_CHECK_NOT_SUPPORTED finally you can see how many updates are being applied to the mounted image and then it commits those changes, verify that all is well in the OfflineServicingMgr.log file before continuing, note that in addition to unmounting the image (commiting changes) it then creates a backup copy of the original WIM file (with a file extension of BAK). Also look for the line saying Schedule Processing Completed, this notifies you that all is done. Now Browse to where your original captured WIM file is stored and you should see the original WIM file is renamed to BAK and the new file (larger file as it has updates applied) is in it's place. If you need to keep the original file copy it elsewhere or give it a new name. Step 5. Review our updated Image in the ConfigMgr Console. Now that the OfflineServicing process is complete, lets examine the WIM file in Operating System Images (click refresh to update the display). You should see that the Scheduled Update Status says Successful, and that the Update Status tab lists the state applicability of the 78 updates it referenced in the OfflineServicingMgr.log file. Right click on our Windows 7 X64 Enterprise image and choose Properties, click on the Installed Updates tab, here you can see when any updates were added via Offline Servicing (in our case, it was 9 updates and they are indeed listed in the Date Installed column. Step 6. Update your image to your Distribution Points The last part of this process is to update your newly updated image to our Distribution Points, this is not done automatically you must do it yourself, this means that the scheduled task can run (Offline Servicing) and when it's done, you have to review the changes made before you decide if you want to update the image to your DP's or not. Select our image and click on Update Distribution Points in the ribbon click ok When prompted That's it, you've now injected Windows Updates (CBS) using a new feature in ConfigMgr 2012 called Offline Servicing, once the WIM image has completed updating to the DP's your Task Sequence will reference the New updated image and your Enterprise (LAB) will be using the most secure, most up to date image available. Related reading Customizing Offline Servicing of Operating System Images -http://blogs.technet.com/b/configmgrteam/archive/2013/07/15/customizing-offline-servicing-of-operating-system-images.aspx Increase the OfflineServicingMgr.Log file size

sounds like they are working just fine then !

i didnt see any reference to UDA in your smsts.log file, check again, verify it's being set in your task sequence like i've specified in the guide ok ?