Lucid

For Windows 7, I think there's a GPO setting you can configure to delete profiles after X amount of time. Otherwise your favorite search engine will probably be the best bet to find a script that works for your environment. Something like this maybe: http://hardforum.com/showthread.php?t=1497826

I think it pretty much depends on how big your site is and how much traffic you have. Under 10GBs of data pulling from one server is pretty small for a lot of environments. http://technet.microsoft.com/en-us/library/bb932150.aspx

Regarding your GUID comment, you might take a quick read through this: http://www.myitforum.com/forums/tm.aspx?high=&m=201030&mpage=1#201040

I should also add, that you may need to make sure your command is working from a non-standard location. http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/percent.mspx?mfr=true http://blogs.catapultsystems.com/jsandys/archive/2009/08/30/current-directory-in-configmgr-programs.aspx

Since nobody has chimed in I thought I'd toss this out there.... Keeping in mind I don't use the UDI stuff... The "PrintKey2000.exe" file is in the source files for the package, correct? Have you tried using "C:\Windows\system32\Xcopy.exe" in your batch file to make sure it's trying to use the right utility? Otherwise, here's some rough VBScript code that you could try using: Option Explicit Dim objWshShell, objFSO, SystemDrive, strScriptFileDirectory Set objWshShell = WScript.CreateObject("WScript.Shell") Set objFSO = CreateObject("Scripting.FileSystemObject") SystemDrive = objWshShell.ExpandEnvironmentStrings("%SystemDrive%") strScriptFileDirectory = objFSO.GetParentFolderName(wscript.ScriptFullName) If objFSO.FileExists(strScriptFileDirectory & "\PrintKey2000.exe") Then objFSO.CopyFile(strScriptFileDirectory & "\PrintKey2000.exe"), (SystemDrive & "\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\PrintKey2000.exe"), True End If Wscript.Quit

It depends. What do you WANT to delete? Are you concerned about size issues with your .WIM file? Before we switched to an automated Build and Capture task sequence within SCCM, we'd at least do the following (it's a little out of date, so take it with a grain of salt): Restart the machine to ensure that everything is running smoothly, and then clean up the following final items prior to capturing the machine: a. Clear the Internet Explorer (version 8.0) browsing information: i. Open Internet Explorer and select the Tools | Internet Options menu item. ii. Click the Delete button within the Browsing History section. iii. Checkmark ALL of the boxes, and then click the Delete button. iv. Click the OK button to close the Internet Properties window. v. Close Internet Explorer. b. Clear out the Problem Reports and Solutions information: i. Start | All Programs | Maintenance | Problem Reports and Solutions ii. Click the Clear solution and problem history link item. iii. Click the Clear all button on the window that appears. iv. Close the Problem Reports and Solutions window. c. To clear out the downloaded Windows Updates, perform the following: i. Right-click on Computer and select Manage. ii. Expand the Services and Applications node. iii. Highlight the Services node. iv. Double-click on the “Windows Update” service. v. Click the Stop button. 1. This is a delayed start service, so it may already be stopped. If so, proceed to the next step. vi. After the service has been successfully stopped, click the OK button to close the Properties window. 1. Leave the Computer Management console open. vii. Delete the contents of the following two folders (empty the Recycle Bin when done): 2. C:\Windows\SoftwareDistribution\DataStore 3. C:\Windows\SoftwareDistribution\Download viii. Within the Computer Management console, double-click on the “Windows Update” service. ix. Click the Start button. x. After the service has been successfully started, click the OK button to close the Properties window. xi. Close the Computer Management console. d. Delete additional unwanted files and folders if they exist: i. C:\Windows\Panther\unattend.xml ii. C:\Windows\System32\sysprep\unattend.xml iii. C:\MININT iv. C:\PerfLogs v. C:\Windows\Security\Database\secedit.sdb (if the machine has been joined to a domain). 4. This should prevent any domain group policies from being accidentally integrated into the image if the machine was joined to a domain. vi. C:\VIRTPART.DAT 5. This file is generated when using Symantec Ghost. e. Remove unwanted files using the Disk Cleanup tool: i. Start | All Programs | Accessories | System Tools | Disk Cleanup ii. Check ALL the boxes except “Setup Log Files”, and then click the CK button. iii. Click the Delete Files button on the window that appears. f. Re-Enable System Restore: i. Right-click on Computer (located on the Start menu) and select Properties. ii. Click the Advanced system settings link button. iii. Click the System Protection tab. iv. Check the box for the desired Available Disks. v. Click the Apply button. vi. Click the OK button to close the System Properties window. vii. Close the System window. g. Delete the contents of “C:\Windows\prefetch”. h. Delete the contents of “C:\Windows\Temp”. i. Clear out the frequently used programs list on the Start menu. j. Clear out the recent items list on the Start menu. k. Empty the Recycle Bin.

In your Build and Capture task sequence, do you have it joining a WORKGROUP? And you don't have to install the sysprep tools on a Windows 7 capture, like you do with XP, because they're built in. So you might try just blowing that open away, or at least making sure it's marked as disabled under the Options tab. Also, if you want a different view on the process to capture and deploy Windows 7, you can look here: http://myitforum.com/cs2/blogs/rbennett806/pages/using-sccm-to-capture-and-deploy-windows-7.aspx

SCCM doesn't move existing Active Directory computer account objects. That path is for brand new ones. And you're picking up the same name probably because that machine's MAC address is already registered within the SCCM database with that particular name. If you deleted the resource object for that machine from SCCM it should pick up a new name. But most people either pre-populate the MAC address/computer name before they image a machine, or else use an HTA frontend to do it on-the-fly at the start of the imaging process...

When in the WinPE phase it will be using the NAA account you set up. Shweta gave you the location to check that in his post above, but just as a double-dose... (Site Management | YourSiteName | Site Settings | Client Agents | Computer Client Agent). Make sure that account name is the one you're granting access to. Also, make sure it hasn't gotten locked or screwed up out in Active Directory (might try resetting the password so you KNOW it's the one you think it is). And if you're checking stuff with NET USE, then try using that account's info to make sure it really can get access. Also, let me ask this, is this your first OSD image, or had everything been working fine previously?

Just tossin these out there... Does the account have rights to wherever you've got the OS .WIM file stashed? So it can copy it up to the DPs. And are they the same DPs you use for your software deployments (Flash and Office)? Did you try updating your OS image to see if it successfully updates to the DPs? And when you check permissions you're checking Share and NTFA, right? Just in case someone accidentally changed something. And what happens if you create a brand new test task sequence? Does it work, or does it fail too? I've seen them get corrupt and have to be recreated in order to fix the problem. And if everything was working 2 weeks ago, try to think back through what you tweaked and looked at for RAP. Maybe you forgot to switch a setting back after running a test or something....

Oh, and one more resource for HTAs: http://www.windows-noob.com/forums/index.php?/topic/1064-sccm-2007-guides/page__p__11753#entry11753

What is an HTA: http://msdn.microsoft.com/en-us/library/ms536496%28v=vs.85%29.aspx basically, think of HTAs as GUI wrappers around scripts - so they give the user an interface to interact with. And there are probably a ton of HTAs out there, but you should at least check out Microsoft's UnknownSystem.hta file found in the SCCM SDK (http://www.microsoft.com/downloads/en/confirmation.aspx?familyId=064a995f-ef13-4200-81ad-e3af6218edcc&displayLang=en). Once you download and install the SDK, look in C:\Program Files\Microsoft System Center Configuration Manager 2007 SDK\Samples\OperatingSystemDeployment\UnknownSystem\VBScript\ If you've got specific tasks you want to have an OSD frontend HTA perform, feel free to ask them on the forums. Since there's a wide array of environments out there, chances are that someone may already be doing what you want to do...

I think your list is fairly good. Each environment sees different things as being the priority. One more might be....If you base things on computers, you typically have less work. Which means it costs the company less. If you want more, I think Sherry Kissinger (skissinger) posted some reasons over in the http://www.myitforum.com/forums/System-Center-Configuration-Manager-f144.aspx SCCM forum at one point in time...

I thought I'd toss some things out there, but hopefully others will chime in as well... 1. I think that if you've got someone on staff that can write basic VBscripts, then SCCM can do just about anything you want it to. 2. We use an HTA frontend on our OS deployments so that the techie out in the field can select the department, OU location, OS type, enter the Active Directory Description and Location field information, and a few other things. Once that's done, the SCCM OSD process kicks in and they select the desired OS based on those advertised to the collection where the resource object now resides (our HTA process moves it around if needed). 3. Our OS deployments kick off a VBScript at the end of the process to customize the OS - we do ALL sorts of things. From setting themes and desktop background to adjusting Windows settings and icons. 4. A typical SCCM OS deployment involves an OS .WIM image that you've captured (it's based off your MS DVD and includes Updates and apps that you want). 5. The biggest issue you'll run into is screen resolution. Since a typical (note I keep saying "typical") OS deployment installs only the needed drivers on the fly, the resolution may change based on the video driver getting installed. We try to set it in the unattend.xml file, and if it happens to change, the techie in the field can adjust it once the process is done. 6. We also use Jason's OSD AppTree utility so we can easily install one-off software on the fly as we image a machine (so everything doesn't have to be baked into the .WIM image). 7. Since we now have an automated Build and Capture task sequence we normally capture a new OS .WIM image every other month so that it's up to date. in between we just rely on the WSUS service to push out the updates. That, and the techies in the field are trained to log in once the machine is imaged and install any missing updates or drivers (normally takes less than 10 minutes). So... Bottom line.... Yeah, SCCM can probably do everything you want it to do, but it ain't gonna do it straight out of the box. You'll have to write some scripts (or adjust pre-existing ones) and learn to use task sequences...

I agree with Peter, I think you may want to focus on capturing an image with very few drivers, and then deploy the drivers when you deploy your image. This way you can have a lot more flexibility with the drivers (using WMI queries). That, and you get rid of the headache of trying to get all the drivers to play nicely together. Just capture the base image, and then add the drivers to the SCCM repository. The Build and Capture process should use very few, if any, drivers...

Does this help? http://blogs.technet.com/b/aaronczechowski/archive/2008/11/11/configmgr-software-updates-on-an-isolated-network.aspx

Does your task sequence erase the drive and create a new partition before it begins to pull down the image? If so, you may want to check this out to see if it's relevant: My link

It may have squirreled up somewhere when writing the file. I'd suggest right-clicking on the Apply Operating System task sequence item, and selecting Copy. Then right-click on an empty space in the task sequence and select Paste. Then delete the original Apply Operating System item. Move the new item to the desired spot, and then save the task sequence. Then give things a whirl to see if that fixed it...

Correct. The sysprep process is built into the processes that are run by the SCCM Capture Wizard CD. So there's no need to kick it off manually...

Does this help? http://www.myitforum.com/forums/tm.aspx?m=185768 http://www.rlmueller.net/freecode3.htm And for my own personal two cents... I'd suggest trying to stay away from user-based deployments since they can get sticky at times...

Have you thought about using a Task Sequence to install the software? You could have it connect to a share on the Host server, and then simply use the next step in the task sequence to fire off the installation via the newly mapped drive. Then once it installs (or fails), have ConfigMgr restart the machine to remove the connection if need be...

Is there a reason you don't mesh it all together into a single task sequence? Let it kick things off, deploy the base OS, have it run any additional task sequence items, and then it automatically captures the setup and generates your .WIM file. Anyway, if I understood your question, then I think you want to hear... The capture process uses the drivers via the installed OS initially, and then once it reboots, and initiates WinPE, it switches over to the drivers you've got added to your boot image. So to have a successful capture you probably need to have your NIC and maybe SATA drivers for the particular model in two places - in the SCCM repository, but also added to your boot image. I'm not sure what you mean when you ask about "after"...

Since nobody has chimed in yet... First off, have you gone through the deployment guides pinned to the top of the Windows 7 forum? I'd suggest going through them once, and deploying the OS via boot media to ensure that you've got everything in place. Of course, I'm assuming this is your first attempt at OSD using SCCM... Oh, I should also ask... Is there anything helpful in the advertisement log say within the SCCM Console (System Status node | Advertisement Status node | advertisement name)? It may help pinpoint your problem...

Are you using a Build and Capture task sequence, or are you inserting the Capture Wizard CD and kicking things off manually?

I'd also suggest looking into using Active Directory groups. You can then grant access to add/remove accounts to the domain group without having to give someone access to SCCM. Also, you can probably save time by using AD and a dynamic membership query. We actually set our advertisements to always rerun. This way, if an application gets uninstalled for some reason, the processes will later put the computer back into the collection and it'll get the app installed again. Here's an example of a dynamic collection query that uses domain groups: select SYS.ResourceID,SYS.ResourceType,SYS.Name,SYS.SMSUniqueIdentifier,SYS.ResourceDomainORWorkgroup,SYS.Client from SMS_R_System AS sys WHERE sys.ResourceID NOT IN (SELECT ARP.ResourceID FROM SMS_G_System_ADD_REMOVE_PROGRAMS AS ARP WHERE ARP.DisplayName = "Google Earth" AND ARP.Version = "5.2.1.1588") AND sys.SystemGroupName = "YourDomain\\SCCM-Google Earth 5.x" Oh, and we limit our collections to another collection that only contains healthy clients (so we never beat our heads against the wall trying to figure out why the app isn't going out).