Trevor Sullivan

You'll want to check out your smsts.log file for details on why it's failing. Is the entire process hanging, or is it giving you an error? Check sysprep.exe logs as well: http://technet.microsoft.com/en-us/library/cc766514(WS.10).aspx Hope this helps. Cheers, Trevor Sullivan http://trevorsullivan.net http://twitter.com/pcgeek86

Hmmmm not quite sure where to start here -- I'd suggest maybe removing the SUP, removing WSUS, and then re-installing WSUS to use port 8530 instead of port 80. Then, re-install the SUP role. Let us know if these steps work. Hope this helps. Cheers, Trevor Sullivan http://trevorsullivan.net http://twitter.com/pcgeek86

Do you have a maintenance window preventing them from installing? What happens if you disable the user interaction — have you tested this? Hope this helps. Cheers, Trevor Sullivan http://trevorsullivan.net http://twitter.com/pcgeek86

Use a WMI browser, such as wbemtest or SAPIEN WMI Explorer to retrieve instances of SMS_R_System, and then examine the value of the SystemGroupName property on a few, random instances. This will ensure that the data is being pulled properly from Active Directory, is being populated into the SCCM database, and is retrievable through the SCCM provider. Hope this helps. Cheers, Trevor Sullivan http://trevorsullivan.net http://twitter.com/pcgeek86

Hello, Can you post the command line you're using to install the SCCM client to point to the new site? You should probably be using some combination of the following MSI properties: SMSSLP=newsccmserver.mydomain.loc FSP=newsccmserver.mydomain.loc SMSMP=newsccmserver.mydomain.loc SMSSITECODE=auto You could use the /mp: switch (not a MSI property) to make sure that ccmsetup.exe downloads the client source files from the new management point. Without this switch, it's quite possible that ccmsetup.exe would locate the default management point from Active Directory, and therefore download the client source files from your old infrastructure. One more thing: when site code assignment fails, have a look through the client log files. This will help you troubleshoot why the manual assignment is failing. Hope this helps. Cheers, Trevor Sullivan http://trevorsullivan.net http://twitter.com/pcgeek86

Have you checked out the adsysgrp.log on your primary site server? That should help you in debugging this issue. Hope this helps. Cheers, Trevor Sullivan http://trevorsullivan.net http://twitter.com/pcgeek86

You install R2 / R3 on the primary site server, and then there is a ConfigMgr R3 client update. Hope this helps. Cheers, Trevor Sullivan http://trevorsullivan.net http://twitter.com/pcgeek86

You're in luck -- it's easy to use PowerShell to automate package creation, since almost everything in SCCM is done via the WMI interface (provider). I would write some code myself to demonstrate this, but it appears someone else has already done so (I also have to head out to the airport right now): http://www.powershell.nu/2010/10/07/powershell-sccm-packages/ Let us know if you need more specifics, but hopefully this points you in the right direction! It's a pretty well-written article. Hope this helps. Cheers, Trevor Sullivan http://trevorsullivan.net http://twitter.com/pcgeek86

Hey there, welcome to the forums. Since you're most likely going to have overlapping site boundaries, I would recommend leaving AD publishing disabled on the new SCCM infrastructure. Install the server locator point role and for the time being, install clients using a batch file that points them to your new Management Point (SMSMP MSI property) and Server Locator Point (SMSSLP MSI property). Technically you shouldn't need the SLP if you also manually assign the site code (SMSSITECODE MSI property), but it's a good safety fallback. Once you've migrated all your clients to the new infrastructure, decomission the old one and enable AD publishing on your new primary site. Hope this helps! Cheers, Trevor Sullivan http://trevorsullivan.net

Join the MyITforum.com ConfigMgr mailing list also! http://www.myitforum.com/absolutenm/EmailLists.aspx Cheers, Trevor Sullivan http://trevorsullivan.net http://twitter.com/pcgeek86

Check your smsts.log to make sure that the driver is getting copied down to the system. If it's getting copied down, then check the %WINDIR%\inf\setupapi.dev.log file to debug driver installation. The MSDN documentation for the Windows Driver Development Kit (DDK) will be helpful in debugging this issue. You may have to sift through the INF files to figure out why it's not applying properly. Also, is the driver digitally signed? Windows 7 has much more stringent requirements for driver signing than XP did. Hope this helps. Cheers, Trevor Sullivan http://trevorsullivan.net http://twitter.com/pcgeek86

All this does is pre-define certain things for you. You're probably better off managing the whole process yourself, and making sure that your command lines are correct. I rarely like to use templates for anything (this included), because I usually do things differently from most people. My suggestion: Just continue defining your packages and programs yourself. Hope this helps. Cheers, Trevor Sullivan http://trevorsullivan.net http://twitter.com/pcgeek86

Yes, you have a couple of options: 1. Write a wrapper script around the deployment that checks for existence of the software first. 2. Put the deployment inside a task sequence, and deploy the task sequence instead. You can set a conditional (such as a WMI query) on each task sequence item, so if the condition is met, then the software will not install. Hope this helps. Cheers, Trevor Sullivan http://trevorsullivan.net http://twitter.com/pcgeek86

Objects created on a given site must be managed at that site. In this case, the collections you created at the central site must be managed at the central site. You can create collections on the child primary site as well, but you will need to manage them from the child primary site. Hope this helps. Cheers, Trevor Sullivan http://trevorsullivan.net http://twitter.com/pcgeek86

Assuming that ccmsetup.exe is getting kicked off, you'll want to check the contents of the ccmsetup.log file (64-bit = %WINDIR%\ccmsetup; 32-bit = %WINDIR%\System32\ccmsetup). Hope this helps. Cheers, Trevor Sullivan http://trevorsullivan.net http://twitter.com/pcgeek86

We can use PowerShell to translate the Win32 error code into a [more] useful description: PS C:\Users\trevor.sullivan> [componentmodel.win32exception]0x800700FF The extended attributes are inconsistent http://learn-powershell.net/2011/06/28/quick-hits-translate-windows-error-codes/ Hmmmm, in this case, it's still a bit of a confusing error message. What extended attributes -- is it talking about file attributes? Probably not, since I'm not aware of any attribute "extensions" for the NTFS filesystem. Here's one thing ... as a best practice, I always recommend that when building and testing packages or scripts in SCCM, before deploying it through SCCM, simply try running the command line as the Local System account. How do you do this? Download Sysinternals psexec, and use the -s parameter to invoke a command as Local System. This will help to ensure that your command still works even when SCCM executes it as Local System, rather than your user credentials. Hope this helps. Cheers, Trevor Sullivan http://trevorsullivan.net http://twitter.com/pcgeek86

Exit codes are not determined by Microsoft, but rather by the software's developer (Adobe, in this case). I suggest contacting them to find out what 1040 means. Hope this helps. Cheers, Trevor Sullivan http://trevorsullivan.net http://twitter.com/pcgeek86

Download Roger Zander's SCCM client center, and see if you can figure out what's missing -- it'll let you do things like show installed updates, enumerate targeted deployments (I think), and so on. http://sourceforge.net/projects/smsclictr/ Hope this helps. Cheers, Trevor Sullivan http://trevorsullivan.net http://twitter.com/pcgeek86

Hello, You can only have a single active Software Update Point (SUP) per SCCM hierarchy. http://technet.microsoft.com/en-us/library/bb632674.aspx Putting the SUP role on the central site is your best bet. Remember that only software update metadata is retrieved from the SUP -- the actual package content is pulled from local distribution points that have replicas of your software updates packages. If you're having trouble distributing your software update packages across the WAN, I'd suggest re-evaluating the configuration of your distribution points. Usually DPs handle low-bandwidth / high-latency links pretty well, but if not, maybe you need to restrict their transfer rates a bit manually. Hope this helps. Cheers, Trevor Sullivan http://trevorsullivan.net http://twitter.com/pcgeek86

Do you know why the software updates reports are not giving you the proper status? Failing that, I'd recommend creating a Desired Configuration Management (DCM) rule to perform the validation locally on each client, and then send the status up to the SCCM site. DCM configuration items (CIs) are easy to run compliance reports against. You'll have to find some sort of criteria on your own to validate that the updates are installed (eg. existence of a file or registry value, or maybe a WMI query). Hope this helps. Cheers, Trevor Sullivan http://trevorsullivan.net http://twitter.com/pcgeek86

Perhaps you could post the problem (symptoms), your investigative steps, and your solution? This could potentially benefit the whole community, rather than simply seeing a thread that says "I solved it." Hope this helps. Cheers, Trevor Sullivan http://trevorsullivan.net http://twitter.com/pcgeek86

Hello Constantine, In answer to your question, SMS_R_SYSTEM is a Windows Management Instrumentation (WMI) class definition that resides in the SCCM provider's WMI namespace (eg. root\sms\site_lab). It directly maps to the SQL view (not table) named v_R_System in your SCCM database. When SCCM populates "system resources" into collections, those system resources represent instances of the SMS_R_SYSTEM class. If you look at the WMI class definition, you'll notice all the same properties that show up in a collection enumerated inside the console. Examples of those properties are: Name, Domain, Client, Active, Obsolete, and so on. Hope this helps. Cheers, Trevor Sullivan http://trevorsullivan.net http://twitter.com/pcgeek86

Hello, You'll have to delegate permissions to the SCCM objects (and SCCM provider) to the users that you want to be able to modify these collections. Since it sounds like you're tightly managing these department-based collections, you'll probably want to give them instance-level permissions (allows the to modify specific collection(s)), rather than class-level permissions (allows them to modify all collections). Adding / removing individual machines is typically done with Direct Membership rules, rather than query-based rules. You could have a subselect query that allows you to exclude machines not in the subselect query. Automating the management of WMI Query Language (WQL) collection queries seems like it would be a pain though. You're probably better off sticking with direct memberships. Let me ask you this, though ... what are you trying to accomplish by creating these collections though? Is there some reason you can't manage all the systems based on other criteria, rather than who's "responsible" for a particular department? There may be some opportunity here to optimize the organization of your team's administrative responsibilities. Hope this helps. Cheers, Trevor Sullivan http://trevorsullivan.net http://twitter.com/pcgeek86

Hello Tom, In your config.xml for your Microsoft Office 2010 deployment, go into the Logging XML element, and change the value of the "Type" attribute to "Verbose". If necessary, you can change the "Path" and "Template" attributes to move the location of your log files on the filesystem. http://technet.microsoft.com/en-us/library/cc179195.aspx#ElementLogging Then, run the setup again and look through the log file (or post it here for assistance). "1603" is a generic error returned by the Windows Installer service (msiexec.exe) -- unfortunately, that in itself doesn't tell us much. With verbose logging enabled though, we should have much more information to work with Hope this helps. Cheers, Trevor Sullivan http://trevorsullivan.net http://twitter.com/pcgeek86

Sounds like a vendor driver problem. The error code stands for "The parameter is incorrect." Sounds to me like the vendor isn't passing certain parameters to certain functions properly. Are you deploying Windows 7 with Service Pack 1? I wonder if there are some printer-related hotfixes in SP1 or later ... make sure your base WIM is fully patched before deployment. Hope this helps. Cheers, Trevor Sullivan http://trevorsullivan.net http://twitter.com/pcgeek86