anyweb

that's not possible for SCCM 2007 to SCCM 2012, it has to be side by side when migrating to SCCM 2012.

remove the cd key (if specified) in the apply operating system step, does it work then ?

where are you getting that error exactly ?

yep, read it again - http://www.windows-n...-windows-7-x64/ see the bit's in blue below in other words, get your ISO (or dvd) and extract the contents of that ISO to your chosen share so that every file and folder that's on the DVD/iso will be on the share.

looks like you created the operating system installer package incorrectly, so check the guide again, it tells you exactly how to create it cheers niall

ok and have you uinstalled the WDS role (from server manager),. and then uninstalled the DP role (from within Configmgr) and then rebooted, then added back the DP role ?

unisntall the wds service, uninstall the DP role, reboot server, reinstall the distrubution point role, wait 10 minutes, see if the WDS service has started

nope, they should not be that way, only in a lab if you WANT it that way, but i'd recommend you keep them separate. so are you saying that you do have AD setup currently, is that working ok ? is DNS ok, from your sccm server open a command prompt and type nslookup, what does it return, you can include a screenshot

did you distribute both boot images to the dps ? did you check if the windows deployment services service is started ?

currently you can only deploy one task sequence, so.... thinking like that you can have multiple os's in one task sequence, just make the ts bigger, and have a frontend hta or similar to decide was os you are installing.

and make sure you've got your site assigned in the boundary group, check Heirarchy Configuration, Boundary Groups, and click on the references tab, is your site assigned ?

Before the Internet, updates such as service packs and "patches" were impossibly hard to come by. You ordered upgrade "media" or maybe bought a magazine with a CD in it. Of course, the Internet changed all that. In fact, when ftp.microsoft.com was first set up, among the first services was the ability to get updates for MS-DOS and Windows. With the introduction of Windows Update, we invested heavily in building not just a software delivery service, but a commitment to delivering high quality updates in a timely manner. It took some time to get to the point where customers trust these automatic updates, and we're proud of how far we've come. Today Windows Update is one of the largest services on the Internet by several measures, and of course we're using Windows 8 development as a chance to improve the experience of product updates too. This post was authored by Farzana Rahman, the group program manager of our Windows Update group. –Steven When it comes to Windows Update, one of the most discussed topics is the disruptiveness of restarts in the course of automatic updating. And for good reason—restarts can interrupt you right in the middle of something important. The obvious question to ask first is why does the installation of updates even require a restart at all? Ideally, we would like all update installations to happen seamlessly in the background without a restart. But, in reality, there are situations where the installer is not able to update files because they are in use. In these cases, we need to restart your machine to complete the installation. The automatic updating experience thus needs to be able to handle cases where restarts are required. We know this architectural challenge is one that frustrates administrators and end-users alike, but it does represent the state of the art for Windows. It is important to understand that for many updates, even if you could continue running the existing code that is already in memory, it is that very code that is a security vulnerability (for example), so the risk to the security (or reliability) of the machine would remain until you restart your machine. We'll keep working on this one. In the meantime, applications that support the Windows Restart Manager (introduced in Windows Vista) can return you to precisely where you left off after a restart. In this blog, I want to talk about some of the improvements we are making to the automatic updating experience in Windows 8, which will make restarts a little less annoying. First, some facts about Windows Update Windows Update (or WU, as we like to say within the team) currently updates over 350 million PCs running Windows 7 and over 800 million PCs across all the supported Windows platforms. There are actually many more PCs updated by WU indirectly if you account for our Windows Software Update Server, and for those machines (or customers) that do all updates manually for any number of reasons. Since its genesis over a decade ago, the Windows Update experience has evolved quite a bit to adapt to a changing ecosystem, especially the changing requirements around security. And Windows Update has been quite successful in updating PCs in time to stay ahead of large-scale exploits against Windows. Since the introduction of automatic updating, we have constantly worked to tighten the time it takes to distribute new updates to everyone who uses WU. The chart below (figure 1) shows us how fast downloads and installations occur on Windows 7, from the time of release of an update. The speed of each download is primarily determined by the internet connectivity of the PC, something that WU has no control over, so it is interesting to see below that the majority of update activity occurs in the first three days after release. This three-day number is a key one that I will come back to when we talk about improvements in Windows 8. In one week, 90% of users worldwide who need the update have successfully completed installation, including the restart, with the number of installations pretty much flattening out after that. Figure 1 – Completed download and installation of updates from time of release of update The balance of how broadly and how quickly we can update has proven beneficial to our users to the point where updating is mainly viewed as a background maintenance task (and justly so!) with nearly 90% of users choosing to update automatically on Windows 7. That’s 90% of the total user base telling us to automatically install updates without showing any notifications, or asking for confirmation. Windows 7 Automatically install updates 89.30% Notify me before install 2.38% Notify me before download 3.44% Never check for updates 4.88% Figure 2 – Usage of various modes of automatic updating Automatic updating and restarts on Windows 7 The next logical question to ask is what is the install experience for people who have chosen to automatically install updates? Below, data collected anonymously from WU gives an insight into the various modes of installation for those who have chosen to install automatically. As you see above, there are 3 main categories of automatic update installations. Here is what we learned from analyzing each category. Install-at-shutdown – The majority of automatic update users (39%) are updating when they shut down their systems. For these users, there is no automatic restart because the system can complete all steps of the installation during shutdown. This is the least disruptive experience for users, and so we do want to “hitch a ride” whenever we can on user-initiated shutdowns instead of inconveniencing users with a separate restart. Install-at-scheduled-time - For the 30% who are scheduling automatic updates, their installations start at a scheduled time (the default is 3 AM in the time-zone where the PC is located) or the next time the user logs in (if we miss the 3 AM window). WU automatically completes any restarts necessary to finish the installation. To ensure that you get the chance to save any important files and data before the restart, we show you a 15-minute countdown timer before the restart. A fifteen-minute countdown timer warns you of the restart Allowing restarts to occur without user interaction has helped us to rapidly update a major portion of the Windows ecosystem with critical updates. On average, within a week of releasing a critical update, 90% of PCs have installed the update (see Figure1). On the other hand, this behavior of automatic restarts has some unintended consequences for the user. Restarts can occur without notice, and might occur monthly or even more often if there is an out-of-band update. This unpredictability can potentially result in loss of user data. Most of our automatic installs and the subsequent restarts happen at 3 AM, when users are not around to save any important work. We have heard a lot of painful stories of users coming back to their PCs in the morning to find that a restart occurred, and that some important data was lost. In other cases, the user doesn’t lose data, but needs to restart a job that they were in the middle of (for example, a long copy job). Interactive install - We were surprised to see 31% of users interactively installing updates; of these 31%, approximately 20% have selected to automatically install, but they manually intervene anyway. WU provides a pop-up notification telling you when updates are available if you have selected to automatically install. The notifications are clearly capturing people’s attention, so they click on the notification and interactively install the updates. But this is actually reinforcing an unintended behavior. If you signed up to get automatic updates, you really shouldn’t need to bother interactively installing an update every time one is available. Most installs should occur silently in the background, and WU should notify you only for critical actions (for example, a pending restart). This also matches feedback from customers, who tell us they find the constant notifications to be distracting. Their expectation when they choose automatic updating is that updating will occur automatically. This seems to be a case where making sure people are in control of their PC experience actually resulted in too much information, and ultimately the price of being in control was a feeling of a loss of control. With these lessons learned, we set about defining a better automatic updating and restart experience for Windows 8. Solving the challenge around updating and restarts The question for us on the WU team is always “What is the best way to quickly update the PC while not being intrusive to the user?” Turns out, this is a hard question to answer, and there is no one simple answer. The challenge we faced was to find the balance between updating with speed and giving notice to the user for upcoming restarts. Clearly, updating and securing the PC before vulnerabilities can be exploited is just as important as it ever was. However, we also want to deliver a better experience around handling restarts and avoiding data loss without compromising our goal of timely updating. To this end, the guiding principles we used to design the experience were The automatic updating experience is not intrusive to users but keeps them aware of critical actions Minimize restarts and make them more predictable Continue to keep the PC and the ecosystem up-to-date and secure in a timely manner Windows Update and handling restarts on Windows 8 Based on these principles, we made the following improvements to the Windows 8 updating experience. more > http://blogs.msdn.com/b/b8/archive/2011/11/14/minimizing-restarts-after-automatic-updating-in-windows-update.aspx

i don't have any so cannot test them, feel free to send some my way and i'll test them

that part is already done, what i meant was it was the next part (after the one you had just read) in the series - check it out here

the next part of this series covers this in detail

up to you, normally i'd recommend you keep FAT applications in your build and capture, and deploy everything else in the Deploy Task sequence, but this is just a lab so do whatver you want !

the UDA variables are used to set who the Primary User(s) are for this device, useful for targetting software to computers later... USMT is for migrating users data, we'll come back to that later

cancel out of the wizard, then try again, if it's still not working, reboot the server then try again

software update syncs are carried out by the schedule (check software update point in component services), check the Sync Schedule tab, however that is out of scope of THIS part, so please post those questions separately or on the relevant part, cheers !

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. Now we will setup the Reporting Services Point Role and verify that reporting is working. Reporting in Configuration Manager:- The following reporting features are new or have changed in System Center 2012 Configuration Manager. The reporting point has been deprecated The Reporting Services point is the only site system role used for reporting in System Center 2012 Configuration Manager. For more information about the Reporting Services point, see the Reporting Services Point section later in this topic. Full integration of the Configuration Manager 2007 R2 SQL Server Reporting Services solution In addition to standard report management, Configuration Manager 2007 R2 introduced support for SQL Server Reporting Services reporting. System Center 2012 Configuration Manager has integrated the Reporting Services solution, added new functionality, and removed standard report management as a reporting solution. For more information about Reporting Services, see the SQL Server Reporting Services section later in this topic. Report Builder 2.0 integration System Center 2012 Configuration Manager uses Microsoft SQL Server 2008 SP1 Reporting Services Report Builder 2.0 as the exclusive authoring and editing tool for both Model and SQL-based reports. Report Builder 2.0 is automatically installed when you create or modify a report for the first time. For more information about Report Builder, see the Report Builder section later in this topic. Subscription management Report subscriptions in SQL Reporting Services enable you to configure the automatic delivery of specified reports by e-mail or to a file share at scheduled intervals. Running reports You can run System Center 2012 Configuration Manager reports in the Configuration Manager console by using Report Viewer or you can run reports from a browser by using Report Manager. Each method for running reports provides a similar experience. Localized reporting Reports in System Center 2012 Configuration Manager are rendered in the locale of the installed Configuration Manager console. Subscriptions are rendered in the locale that SQL Server Reporting Services is installed. When you author a report, you can specify the assembly and expression. Reporting in System Center 2012 Configuration Manager provides a set of tools and resources that help you use the advanced reporting capabilities of SQL Server Reporting Services and the rich authoring experience that Microsoft SQL Server 2008 with Service Pack 1 (SP1) Reporting Services Report Builder 2.0 provides. Reporting helps you to gather, organize, and present information about users, hardware and software inventory, software updates, applications, site status, and other Configuration Manager operations in your organization. Reporting provides you with a number of predefined reports that you can use as is or that you can modify to meet your needs, or you can create custom reports. The following topics on Technet help you to manage reporting in System Center 2012 Configuration Manager: Introduction to Reporting in Configuration Manager Planning for Reporting in Configuration Manager Configuring Reporting in Configuration Manager Operations and Maintenance for Reporting in Configuration Manager Security and Privacy for Reporting in Configuration Manager Technical Reference for Reporting in Configuration Manager Step 1. Install the Reporting Services Point Role Perform the following on your SCCM 2012 server as SMSadmin. In the ConfigMgr console, click on Administration, Site Configuration, Servers and Site System Roles, right click on our server and choose Add Site System Roles when the Add site system roles wizard appears click next and select Reporting Services Point from the list of available choices you'll be asked to specify some Reporting Services settings, click on Verify beside database name if all goes well it will be listed as Successfully Verified, now we need to configure a Reporting Services Point Account, and we will use the Active Directory User (called ReportsUser) which we created in Part 1 of this series in Active Directory Users and Computers. * ReportsUser, a domain user for reporting services. so for User Name click on the Set drop down menu and select New Account when prompted for Windows User Account, enter the credentials of your ReportsUser account, you can use Browse to easily find the user in Active Directory. The specified Windows user account and password is encrypted and stored in the Reporting Services database. Note: Reporting Services retrieves the data for reports from the site database using this account and password. Tip: When installing the Reporting Service Point role, you do not have the ability to 'verify' the Reports user you specify, so the user may not even exist in AD. Therefore, you should browse AD when searching for the user. click next to install Reporting Services click next at the summary and review the completion screen. Tip: you can verify that the role installs successfully by monitoring the SMS_SRS_REPORTING_POINT log in Component Status, Monitoring. Look for Message ID 1015 which indicates that the Reporting Services point was successfully installed. In addition you can verify by checking the following Log on your server, SRSRP.LOG located in D:\Program Files\Microsoft Configuration Manager\Logs, look for a line which reads You should also inspect the SRSRPSetup.log file for the following line, Installation was Successful. Step 2. Configure Reporting Perform the following on your SCCM 2012 server as SMSadmin. Now that the Reporting Services Point role is installed we need to do some configuration before we can view reports. In the Monitoring Space of ConfigMgr console click on Reports it will list 0 items. On your ConfigMgr server, click on the start menu and right click on Internet Explorer, choose Run As Administrator, answer Yes to the UAC prompt. enter the following URL http://sccm.server20...b.local/Reports obviously replace your server FQDN in the URL. click on the Properties Tab followed by New Role Assignment In Group or Username enter Server2008R2ReportsUser and give the user the permissions you want now we can see that the ReportsUser has all reporting roles, and as this is a LAB we should verify that SMSadmin has the rights to do everything, select the SMSadmin user and choose Edit, click the Role checkbox so that we get all roles, and then click Apply, after editing both users we want them to have all permissions for Reporting services, Tip: This is a LAB so it's ok to configure Reporting this way, in production you would want to be more specific about what permissions users are granted. exit from Internet Explorer, and browse Reports within ConfigMgr again, the Reports are listed and ready to be used, note that they are sorted by Category (and also below Reports are Category Folders) Step 3. Viewing some Reports Perform the following on your SCCM 2012 server as SMSadmin. In the ConfigMgr console, expand reports, Select the All Collections report, right click it, choose Run, a list of collections appears in the Report Viewer, you can drill down further into the report by clicking on All Systems on one of your Windows 7 Client Computers, login as ReportsUser and start Internet Explorer, browse to http:\sccm.server2008r2.lab.localreports and select a report from the ConfigMgr_P01 database Tip: if the ConfigMgr_P01 database doesn't appear as a temporary measure you can add the ReportsUser to the Local Administrators group on your SCCM server, that's ok in a LAB, in production you'll want to configure your security accordingly and create Groups for Report Readers and Report Administrators. Thats it ! Reporting Services Point is installed and in our next part we will look at our Endpoint Protection reports and monitor it real time both on the Server and Clients.

can you post the SMSPXE.log please

well what issues are you having specifically ? if you think in terms of refresh the only barrier is the encrypted drive, if you unlock the drive and suspend encryption on it then the rest of the refresh is as per normal (hardlinking and so on), the challenge is do you 1. disable the encryption in Windows (most people do this prior to rebooting into WinPE and doing the remaining tasks) 2. disable it if found in WinPE - this is where you have to get creative as the task sequence wants to write to the largest available NTFS drive at boot time... we did solve is though with some clever diskpart commands to reassign the drives followed by a reboot.

because you want your computer(s) installed with applications dynamically as part of the operating system installation, or your just want a task sequence to dynamically install a list of applications in a set order on computers,

unisntall the DP role uninstall WDS, reboot do NOT install or Configure WDS install the DP role, monitor the Distrmgr.log does that help ?