h4x0r

As a minor update as it relates to this thread...I had one of our techs replace a motherboard in a Dell workstation today, and he was having no end of troubles trying to image the workstation...same issues as before: no service tag (duh). What I found out though as I was showing him this, was that the motherboard actually allowed us to edit the service tag field from WITHIN the BIOS. Now, I had previously thought that you couldn't edit this field from BIOS, and I was right...however, with this replacement board from Dell, when I actually brought up the Service Tag screen, because it was blank it let us type in the service tag. It should be noted that this is a one-time deal, and that afterward bringing up the service tag window will give a pop-up alert which says that the information listed is for viewing purposes only. tl;dr--a replacement motherboard from Dell will let you add the service tag of the workstation, without having to boot to a Win98 disk and run the ASSET utility

Yup...that was actually one of my first steps when I was troubleshooting this

I was able to get this resolved with a little help from some friends. Turns out that the size limit for my ReportServer_log.ldf file was over 2TB. Using the SQL Management Studio I was able to go in and change the log file size, and size cap (ReportServer DB . Right-click > Properties > Files ).

We’ve been using SCCM 2012 since its release without any major issues, but I noticed today that we’re fast running out of room on the partition we have SQL2008 R2 installed on, and that the culprit was ReportServer_log.ldf. It is currently 145GB and growing, and nothing I have tried has reduced its size. So far I have changed the recovery node to Simple, performed a backup (which I thought was supposed to flush LDF files?), and performed a Shrink (file based) on our ReportServer DB (though I can't find any listing of ReportServer_log.LDF when using MS SQL Server Management Studio, and it reports that our ReportServer DB is only ~45MB). Any SCCM/SQL gurus out there that could offer some insight into how I can reduce its size, AND keep it from getting this large in the future? Is there a way to pull up/modify the LDF file from the Management Studio? Thanks for any input...I'm at a complete loss here!

[edit] Sorry...I missed your first sentence where you said you created the bootable USB...I just copied the Dell utility right to the USB drive after that. Also, and this just might be a typo in your post, but the file ASSET_A209 has a .COM extension and not a .EXE...but, if you're actually typing it out with the .EXE then that could be part of the problem

I've attached the asset utility from Dell...here is a link for creating your bootable USB drive if you don't have one already. Once you boot up, just run the command with the /s switch, followed by the service tag and it will update the BIOS. Thanks for the query info ASSET_A209.zip

Albeit inconvenient, have you verified that all those 620's have their service tag listed in BIOS? I'm also curious about the duplicate query...do you have that on a collection or run it as a report?

Fortunately this has been resolved now. The issue was that there was no service tag set in BIOS (due to replacement motherboard). We used Dell's ASSET.COM utility with the /s switch to set the service tag via a DOS booted USB drive. Afterward, the workstation had a different--and correctly reported--SMS BIOS GUID upon PXE booting and in the logs. It is currently being imaged as I type this message. Hopefully this will help anyone else who might experience this problem.

I found this link this morning...one of the posts there mentioned an issue with Dell's GX270/280 models which had runs of bad capacitors on the motherboards, and that when Dell shipped out replacement boards for them, that the service tag was not set in BIOS...which of course is what the SMS BIOS GUID is based off of. The ending result is a generic SMS BIOS GUID, so much so that the OP of that thread had the exact same SMS BIOS GUID that I had, all the way down to the reversed sections. We're going to try and correct this and see if that allows us to deploy the OS correctly this time around...will update here when I know more.

So here's the deal...when PXE booting a workstation it displays the MAC and the SMS BIOS GUID-- which I've used before to import a workstation, though usually we just boot workstations as Unknown and deploy an OS through the Unknown Computers collection--but when trying to image this one particular workstation, we noted that it simply kept restarting itself after running the pre-execution hook. Taking a look at the logs revealed that when it begins the identity request, that it is logging a different SMS BIOS GUID than what is displayed when we first PXE boot. This then resolves to a different NetBIOS name (even though the MAC address is logged correctly), which is how I first noticed that the SMS BIOS GUID was wrong. For example, what is seen in SMSTS.log: Preparing Client Identity Request. TSPxe 9/10/2012 2:50:33 PM 1220 (0x04C4) Setting transport. TSPxe 9/10/2012 2:50:33 PM 1220 (0x04C4) Setting SourceID = d25404f6-c37b-4ee8-91c0-c0b6aeaa4cf4. TSPxe 9/10/2012 2:50:33 PM 1220 (0x04C4) Setting site code = ###. TSPxe 9/10/2012 2:50:33 PM 1220 (0x04C4) Setting SMBIOS GUID = 4C4C4544-0000-2010-8020-80C04F202020. TSPxe 9/10/2012 2:50:33 PM 1220 (0x04C4) Adding MAC Address 00:19:B9:24:65:5A. TSPxe 9/10/2012 2:50:33 PM 1220 (0x04C4) So here are how the SMS BIOS GUID's are being reported for the same workstation: 4C4C4544-0000-2010-8020-80C04F202020 <-- SMSTS log file 44454C4C-0000-1020-8020-80C04F202020 <-- pxe boot initialization You can note that they are nearly identical, with the first and third sections pretty much being the reverse of each other. All of my site system and component statuses are fine...no errors there (with the exception of an AD discovery error). On top of this, we had a workstation accidentally get imaged a couple weeks ago due to a duplicate reported MAC address. Interestingly enough, if you checked the MAC address on the workstation then it would give you the correct information, but the DDR client properties in SCCM listed the incorrect MAC. I ran the duplicate MAC address report and found a couple entries listed, and just ended up deleting them at the time (figuring that they would get added back with their correct MAC's, which they have thus far). The issue in this case though is that the client wasn't reporting the correct value back to SCCM (which was obviously not duplicated based on ipconfig /all command from the "supposedly" conflicting workstations)...which is similar to what's happening here with the PXE booting and the SMS BIOS GUID. So all that being said, has anyone else run into this problem or have any ideas on a solution? Please let me know if I can provide further information! Thanks!

Nice...that's another good script for implementing during the TS.

Sorry for the delay...things got bogged down here and I haven't had the time to get back to you. Here are our modified wizard.hta and ZTIMediaHook.wsf files modified files.zip. Items of note: Wizard.hta -- there are a few sections I added to this file...since if we're using it, then it means that one of our techs is on site to image the computer (otherwise we're just imaging it remotely and not using the boot wizard). The first section that differs from Maik's HTA are a few sub routines that I added to prevent the wizard from being closed and WinPE continuing as normal. Secondly, is a quick password validation field...this just uses a simple encryption function to match the input from the password field (you'll need to run the function in its own script so you can get the encrypted string of your designated password). Without the password, then the end user cannot select a TS from the menu. Ultimately this is not something that I am terribly worried about keeping ultra-secure. If a user REALLY wants to try and hack it, then that's fine...they can image their computer and likely lose all their data in the process...the password verification is really more of an idiot prevention measure. ZTIMediaHook.wsf -- I addded a couple extra web service calls to this...most noteably is the IsComputerKnown call. This runs AFTER the wizard has been processed, but before any checks are made for HasOSDAdvert, simply so that users cannot boot an unknown computer and pull down our image (the wizard requires the password input). We have a single TS for our image deployment (and use the custom boot wizard boot image as the boot image with all deployments), with multiple Apply OS steps being dependant on various TS variables (namely related to which image is to be used). In this scenario, we have this TS being deployed to our Deploy XX OS containers, as well as the Unknown Computers container. On our Unknown Computers container we have have the OSDComputerName variable present but blank. The end result here is that when a known computer boots into the wizard, then we can select whichever deployment we want and continue as normal, and if it is unknown then it kicks out of the wizard and proceeds directly to the normal TS menu. Being unknown, we select the TS that is deployed to the Unknown Computers container, and then proceed to fill in needed variables such as OSDComputerName. The computer gets added to SCCM correctly (thus preventing the bug with the delay of being added via the web service), and is still prompted for a computer name. Hope this helps! modified files.zip

We are one child of many in our AD stucure, and there are quite a few others who I know are using SCCM in the same forest, but I dont think many of them use webservices (I may be one of only a few). From what I understand, the web services still function the same with 2012 as they did with 2007, so I'm not too surprised that there isn't much out there in the way of using them with 2012 since it is nearly identical to using them with 2007 (but I could be wrong about this, too!) I'll try to post the code for the custom boot wizard's HTA and such that we use, but it may take me a bit as I'm presently at work and have a couple items that need my attention

There apparently is some sort of bug with his webservice where adding an unknown computer will create an entry for it, but it doesn't get "completely" added to SCCM for a few minutes...thus it sits through the number of cycles waiting for HasOSAdvertisement. We don't use the PrettyGoodFrontendCline...we just use the custom boot wizard. What I ended up doing was modifying part of the HTA wizard in a couple ways. One was to add a bit of user security and so I have a password field set, which if entered incorrectly after three tries will simply reboot the computer, or if the wizard is canceled it will also reboot. The second is to run another webservice call for IsComputerKnown, and if it returns false then I stop the script from continuing and it then dumps the computer right into the standard TS GUI. From there I select our deploy OS TS, and because it is deployed to the Unknown Computers collection, we have to set the OSDComputerName variable...so that's when it gets prompted for the name, AND gets added to SCCM correctly. Unfortunately I just wasn't able to find a smoother way of adding unknown computers simply using Maik's webservice.

Hello everyone, Obviously setting up an ADR for FEP is pretty straight forward, but I was curious what other people are doing with ADR's to handle patch deployment...are there any particular settings you use for filter settings? How often do you have them run? Do you have different ADR's for different patch severity? Thanks for any input!

Good thought...I'll have to look into that

Unfortunately, workstation names go by specific locations and room numbers...so using the MAC address is out of the question. As of right now, I believe that it was SCCM using the MAC address as the computer name when the DDR was getting created by the webservice, since a name wasn't being provided.

It SHOULD be (as a side note, that's what we use to prompt for a name while we don't have the boot wizard up and running fully yet), but I think one of the caveats is that due to the nature of the pre-execution hook, that OSDComputerName variable on the Unknown Computers collection is never created since the webservice ends up creating a DDR for the computer and adding it to the collection selected. I guess a possible way around that would be to duplicate all my OSD collections and simply have a set for unknown computers with the OSDComputerName set...but that wouldn't be as streamlined as I would like I'm going to have a look now at the logs, and also play around with how I can set variables for use with the customsettings.ini to see if that has any effect.

This is mostly for people familiar with MDT scripting/integration... I've been working on this non-stop today trying all sorts of methods to try and accomplish a prompt for computer name at a specific point...I'm certain that it can be done, but I'm losing hope! Here's the scenario...I'm using Maik Koster's web service (v7.3), as well as his custom boot image for OSD, with MDT 2012 integration. With the custom boot image, the pre-execution mediahook runs and performs a series of webservice calls to populate a wizard that allows for TS selection. After the selection is made, it adds the computer to the appropriate collection with the OSD TS and off you go! This works GREAT for known computers...unknown computers are a little different. I can boot unknown computers to the custom boot wizard, and they get added to whichever collection and are added to the server at the same time. HERE IS THE ODDITY: the computers get added with their MAC address as the computer name, as opposed to MININT-###### I've added a successful check in the pre-execution hook to test if the computer is known or not...if it is unknown, then a simple prompt comes up and we can put in the computer name. THE PROBLEM is that I have NO IDEA what variable I'm supposed to set with the input. The pre-execution hook calls ZTIGather and ZTIUtlity...I've tried setting oEnvironment.Item("OSDComputerName")/("HostName") to the input gathered previously...but it didn't change anything (the webservice call is SUPPOSED to use OSDComputerName as the name)...I'm honestly stumped as to what variable I need to set (since it is using the MAC address for the name), OR would be more viable to try and set a (environmental?) variable that the SCCM_Bootstrap.ini/Customsettings.ini uses? For instance the existing webservice call in the ini file looks like this: ----------------------------------------- [AddComputerToCollection] WebService=http://YourWebServer/Deployment/SCCM.asmx/AddComputerToCollection Parameters=MACAddress,UUID,CollectionID,ComputerName MACAddress=macAddress UUID=UUID CollectionID=collectionID ComputerName=Computername <-- THIS IS NOT POPULATED FOR SOME REASON ------------------------------------------ would it be possible to do something such as: ------------------------------------------- MyNewCustomVariable=%SetByScript% [AddComputerToCollection] WebService=http://YourWebServer/Deployment/SCCM.asmx/AddComputerToCollection Parameters=MACAddress,UUID,CollectionID,ComputerName MACAddress=macAddress UUID=UUID CollectionID=collectionID MyNewCustomVariable=Computername -------------------------------------------- I guess that it might be possible that SCCM is inserting the MAC address to use as the computer name since/if it isn't being provided...but that thought just occurred to me, and I haven't had a chance to look into that possibility. This is all very new to me, as I'm not super familiar with the workings of MDT scripting/customizations. When I get back to work in the morning, I'm going to go through the logs again and see if/where I missed the section that is using the MAC address for the computer name. Hopefully, if I can get this working, then I'll have a very handy method for imaging bare metal workstations with a computer name prompt tied in

I had similar problems when we moved to 2012...I tried to keep the AAS and QuickTime MSI's as part of the same app/package, but deployment kept failing, even with proper dependencies. What I ended up doing was creating separate apps/packages for each and was able to get them to install properly that way.

I believe something like that would be possible with MDT integration, through use of customsettings.ini and the OSDComputerName variable there...I could be wrong, but it might be a place to start looking

Hi Anyweb, Thanks for the guide...one clarifying question regarding the ADR for EP. Is there a special process involved to retire the rule, or are you just disabling the initial ADR and then creating the new one afterwards? Thanks!

I just got this note from Maik:

We currently use Maik Koster's web service with our SCCM 2007 server...anywho, I'm currently downloading the SCCM 2012 Beta 2 VHD to play around with and wanted to know if anyone had done any testing with his or other web services in 2012?