Jump to content


mariorami

Established Members
  • Posts

    10
  • Joined

  • Last visited

Everything posted by mariorami

  1. Hi NickolajA, We are on the process of upgrading the server OS of an SCCM primary site and wanted to ask you what is the best way to approach this. We currently have SCCM 2012 R2 RTM running on a Windows Server 2008 R2. On the SQL side, the DB runs on SQL 2008 on a separate Win2008R2 server. Our goal is to bring a new Windows 2012 R2 server, install a new SCCM site and use the migrate feature. Do you have any recommendations/suggestions?
  2. Ok, After banging my head for a few days with that issue i saw the light at the end of the tunnel ( an not the train) today. Long story short, the culprit was the boot image. I upgraded to 6.3 and everything in my TSs is working as it should. Here are the details. To recall what was my issue, after upgrading SCCM from SP1 to R2, none of the software packages were getting installed in a Task sequence. A TS runs up to the installation of the SCCM agent and then it quits. Looking at the log file in C:\Windows\System32\ccm\logs\smstslog I found the following errors: Resuming Task Sequence in Full OS TSMBootstrap Failed to get the environment key. TSMBootstrap Failed to resume task sequence (0x800700EA). Exiting with return code 0x800700EA TSMBootstrap Earlier i mentioned that my boot images did not get updated as part of the site upgraded, so i went and updated them to version 6.3 and after making sure it got deployed in a TS to make it available through PXE, my problem was gone. this post helped me tremendously to realized that the boot image was the issue: https://social.technet.microsoft.com/Forums/en-US/a793071d-1a3b-4b68-b6de-6d8c1a1fda0f/failed-to-get-the-environment-key-smstslog?forum=configmanagerosd Thank you Peter and Iroqouiz for stopping around to help. Mario.
  3. Thanks Iroqouiz. I have not upgraded the boot images. Still running the same I was using on SP1 which is WinPE 6.2
  4. Hello, I am running into an Issue with software distribution on task sequences after upgrading to Configmgr 2012 from SP1 to R2 I have a single site with two DPs that were upgraded to Configmgr2012 R2 and then with CU3 The upgrade process ran smoothly but now I am having an issue with software packages in task sequences. Ever since after the upgrade, none of the software packages,with the exception of the Configmgr client, are getting deployed on a TS. I looked at the DPs and the packages content has been distributed. When imaging computers, task sequences successfully run go up to the OS Installation and the configmgr client tasks. What is interesting is the the packages are available on the Software Center, even on the recently imaged computers (the ones that didn't get the packages installed during he TS). I can add more information from the TS logs but first wanted to see if anybody has experienced similar issues after the upgrade and how you figured the problem out. Thanks for looking. Mariorami.
  5. I will start making sure both the x86 and x64 boot images have been added to the PXE DP. even if only the x86 boot image is being used to boot, the x64 one will be used for PXEboot in x64 systems and then the x86 WinPE package will be loaded.
  6. I found these two blogs that talk about the same issues i am experiencing. I think they are on the right path but would like to know if any of you have tried the solution they suggest. http://dragos.madarasan.com/tag/guidcount http://myitforum.com/cs2/blogs/idany/archive/2008/10/22/how-to-enable-osd-with-duplicate-uuid-in-configuration-manager.aspx Thanks.
  7. Hi, I want to schedule a task to clear the last PXE advertisement to a whole collection. Can that be done using your script? Thanks,
  8. Something I just noticed is that those affected computers have the same GUID. Could that be part of the problem? From my previous post, does "GuidCount=510" mean that there are 510 objects with the same GUID? I went to the console and deleted the existing object for that MAC address and now all of the computers that had the F12 line missing are showing it and are booting to PXE. I do not get it.
  9. I am sorry i am getting back just now. I got sidetracked with other issues . When i take a look of the smspxe.log file, this is what i found for one of the computers where the "F12" line to boot to PXE is not present: ______________________________________ MAC=00:E0:4D:82:3A:1B SMBIOS GUID=03000200-0400-0500-0006-000700080009 > Device found in the database. MacCount=1 GuidCount=510 smspxe 10/7/2011 9:19:36 AM 5596 (0x15DC) [010.001.050.113:4011] Recv From:[140.198.043.008:68] Len:303 293f070 smspxe 10/7/2011 9:19:36 AM 5564 (0x15BC) Executing GetBootAction(70085, SCCM) smspxe 10/7/2011 9:19:36 AM 5596 (0x15DC) No Boot Action for Device (70085) found smspxe 10/7/2011 9:19:36 AM 5596 (0x15DC) ProcessDatabaseReply: No Advertisement found in Db for device smspxe 10/7/2011 9:19:36 AM5596 (0x15DC) _________________________________________ Now, when i compare the log with a good known PXE boot object, this is what is in the log: _____________________ Advertisement results: OfferId:GCC2006E OfferTime:21/03/2011 07:54:00 PackageID:GCC00033 BootImageID:GCC00072 PackageVer: PackagePath:\\SCCM\SMSPXEIMAGES$\SMSPKG\GCC00072\ Mandatory:0 ___________________________________ What could be different when both of objects are member of the same collection? Thanks,
  10. This is my scenario: I have a group of computers (Usually the same model) that do not get the F12 option when booting to PXE, they get the abort message right before F12 option. I have found that if i clear the last PXE advertisement for the collections they are members of, in about five minutes later the problem is gone. These are computers that have not been reimaged at least in the last 24 hours. I want to find the cause of the problem. It does not happen with all of the computers in the collections. Any idea how to prevent this from happening will be appreciate it.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.