DELL-Greg R's Posts

DELL-Greg R's Posts

"Hi thanks for the reply. No I have not solved it yet. This was already my assumption that it cannot be used with stand-alone media. Then can you give me some advise how to go further? So if I und... See more...
"Hi thanks for the reply. No I have not solved it yet. This was already my assumption that it cannot be used with stand-alone media. Then can you give me some advise how to go further? So if I understand it want to write something in configmgr provider. But in the TS the correct account with permission to the provider are set. It was also able to create the computer object like that. " The Dell Server Deployment Pack (as well as the other Server Deployment Packs) were built for use with USB (ideal) and CD Bootable Media, and PXE. I don't think any of them will work in a stand-alone media environment. The problem is that ConfigMgr OSD doesn't support mulitple reboots into WinPE, which is required for creating virtual disks, etc. The Server Deployment Packs get around this by writing a custom variable to the computer object in ConfigMgr. Are you required to use stand-alone media? If you have network connectivity and connect to the provider, you should be able to use USB or CD Bootable media - have you tried that yet?
Just to confirm, you solved your issue, right? The RebootStep process does not work with stand-alone media, as it connects to the ConfigMgr provider to set a reboot step on the comptuer object.
ah yes, there was a release in April - Please let me know if any of you have troubles with the April released version. Greg
That's good info to know - I haven't done it that way - I'm going to ask a good friend (and MOF GURU) to take a look at our thread. In the mean time, can you provide more detail? Have you refere... See more...
That's good info to know - I haven't done it that way - I'm going to ask a good friend (and MOF GURU) to take a look at our thread. In the mean time, can you provide more detail? Have you referenced external MOF files before? So on your site server, you have \inboxes\clifiles.src\hinv\SMS_Def.MOF, and Configuration.mof - and you have a third file for the DELL mof, correct? Can you paste the line in that you're using to include the dell mof?
yes, we've done it successfully 🙂 I'm in Dell IT. You only need to run mofcomp on the configmgr Primary site servers in ConfigMgr 2007 - have you appeneded the contents of the Dell SMS_DEF.MO... See more...
yes, we've done it successfully 🙂 I'm in Dell IT. You only need to run mofcomp on the configmgr Primary site servers in ConfigMgr 2007 - have you appeneded the contents of the Dell SMS_DEF.MOF to your SMS_DEF.MOF, made the report modifications you need (setting TRUE or FALSE for each one), the compiled the MOF?
what are you using to deploy? maybe you need to add mass storage drivers?
I *think* you would probably (unfortunately) need to import a custom update that has the same GUID, publish it, and expire it, but I haven't tried it yet - I'll see if I can find more info. Greg
"Is there a version of these instructions anywhere for XP deployments using only MDT 2010?" no, but it should be a similar process - I'll see if I can get an mdt-specific walk-through posted. Greg
also, make sure you have the advert configured to "run from DP". also, are you importing the computer before running the TS?
if you can post the smsts.log details, that will help.
you would need to use something like a preexecution hook (see the configmgr docs for preexecution.hta for an example), and prompt the user for this info, then set the vaules based on custom TS Variables.
dave787 - I talked with the owner of the Dell SCUP catalog yesterday, and confirmed that what you're seeing is 'by design' - we hashed it out a bit yesterday, and I think we agree that's not a desired... See more...
dave787 - I talked with the owner of the Dell SCUP catalog yesterday, and confirmed that what you're seeing is 'by design' - we hashed it out a bit yesterday, and I think we agree that's not a desired state - we (Dell catalog) should be doing is expiring the old update, but leaving them in the catalog for an extended period of time - maye 6 months or a year from when it's expired? we need to remove them eventually, because if not, it would cause significant bloat to the catalog. I'm not sure of the time frame to change this feature - I'm sure it will be a few months, but no firm timeline at this point - I will try to remember to update this thread when the catalog has been modified to keep 'expired' updates. Thanks for your feedback, and helping to improve the product. Greg
I'm going to check with the team and get back with you - I see your point, and see something similar in one of my test labs - I'll post back my findings...Thanks for your feedback.
I checked with our team - they shouldn't be there - check to see if those old bios appear in SCUP - if they are in SCUP, check to see that Expire=True - once Expire=true, you can re-publish updates to... See more...
I checked with our team - they shouldn't be there - check to see if those old bios appear in SCUP - if they are in SCUP, check to see that Expire=True - once Expire=true, you can re-publish updates to wsus, then run your synch in ConfigMgr - that should make them disappear. Greg
thanks for the info - we're updating the wiki page.
what model(s) of sysetms are not working, returning the Error 69??
hm- I'm pretty sure the team expires them, but I'll forward your note and see what they tell me.
sorry - I missed this one - I'll ask the team.
I'll ask.
They posted, then pulled it. . and posted again early this morning - The wiki page has been updated also. Let us know if you have any more problems.