OSD PXE boot: no policy available

Hi,
We have some issues with certain machines, PXE boots says "no policy available" whereas they are in the correct collection.
We found out that the object seems to be corrupt due to the fact we import it manually (via MAC-address) and autodiscovery of groups in which computer objects reside. The latter is needed to populate collections, f.e. we deploy Office 2013 to the a collection
"Office 2013" which queries the AD-group Office 2013.
If we disable the AD Directory Groups Discovery and delete, recreate the object, PXE boot works fine again. However, we 'd need to find out the root cause since we cannot to this every time this issue occurs (and it happens more often lately).
Please advise.
J
Jan Hoedt

Thanks, I know about the PXE-log but that doesn't give us extra info. We 'd need to know how to avoid corruption of the computer object. Leaving as is doesn't solve the problem, pc just won't boot, disabling ad group discovery recreating the object is only
a workaround for now but not acceptable as solution.
Probably the corruption occurs because at the time of creating the object, the ad discovery is done. AD discovery runs every 5 minutes. We need this discovery interval at 5 mintues because after OS deploy immediately applications/packages are deployed based
upon collections (which query AD group memberships).
Jan Hoedt

Similar Messages

  • OSD: pxe boot fails with "failed to get infromation for MP:/"

    Hi,
    We face an issue on pxe boot. It boots into pxe then tries to apply network settings but then reboots.
    Ipconfig is ok, smsts.log says "failed to get information for MP:/oursccmserver.
    Troubleshooting:
    *PXE is working fine when client as well as sccm-server are in same subnet, it fails when in different subnets.
    *Firewall is fully opened, no connections blocked.
    *Ping to sccm-server works fine on dns
    Please advise.
    J.
    smsts.log:
    Missing root CA environment variable from variables file    TSPxe    26/03/2014 16:37:11    288 (0x0120)
    Support Unknown Machines: 0    TSPxe    26/03/2014 16:37:11    288 (0x0120)
    Custom hook from X:\\TSConfig.INI is     TSPxe    26/03/2014 16:37:11    288 (0x0120)
    No hook is found to be executed before downloading policy    TSPxe    26/03/2014 16:37:11    288 (0x0120)
    Authenticator from the environment is empty.    TSPxe    26/03/2014 16:37:11    288 (0x0120)
    Need to create Authenticator Info using PFX    TSPxe    26/03/2014 16:37:11    288 (0x0120)
    Initialized CStringStream object with string: {40AB3050-A926-4BA5-9D17-7423F93CBCD5};2014-03-27T00:37:11Z.    TSPxe    26/03/2014 16:37:11    288 (0x0120)
    Set media certificate in transport    TSPxe    26/03/2014 16:37:11    288 (0x0120)
    Set authenticator in transport    TSPxe    26/03/2014 16:37:11    288 (0x0120)
    CLibSMSMessageWinHttpTransport::Send: URL: oursccmserver.ourcompany.com:80  GET /SMS_MP/.sms_aut?MPKEYINFORMATIONMEDIA    TSPxe    26/03/2014 16:37:11    288 (0x0120)
    [TSMESSAGING] AsyncCallback(): -----------------------------------------------------------------    TSPxe    26/03/2014 16:37:11    288 (0x0120)
    [TSMESSAGING] AsyncCallback(): WINHTTP_CALLBACK_STATUS_SECURE_FAILURE Encountered    TSPxe    26/03/2014 16:37:11    288 (0x0120)
    [TSMESSAGING]                : dwStatusInformationLength is 4
        TSPxe    26/03/2014 16:37:11    288 (0x0120)
    [TSMESSAGING]                : *lpvStatusInformation is 0x8
        TSPxe    26/03/2014 16:37:11    288 (0x0120)
    [TSMESSAGING]            : WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA is set
        TSPxe    26/03/2014 16:37:11    288 (0x0120)
    [TSMESSAGING] AsyncCallback(): -----------------------------------------------------------------    TSPxe    26/03/2014 16:37:11    288 (0x0120)
    WinHttpReceiveResponse (hRequest, NULL), HRESULT=80072f8f (e:\nts_sccm_release\sms\framework\osdmessaging\libsmsmessaging.cpp,8927)    TSPxe    26/03/2014 16:37:11    288 (0x0120)
    failed to receive response with winhttp; 80072f8f    TSPxe    26/03/2014 16:37:11    288 (0x0120)
    m_pHttpTransport->Send (0, 0, pServerReply, nReplySize), HRESULT=80072f8f (e:\nts_sccm_release\sms\framework\osdmessaging\libsmsmessaging.cpp,5159)    TSPxe    26/03/2014 16:37:11    288 (0x0120)
    MPKeyInformation.RequestMPKeyInformationForMedia(szTrustedRootKey), HRESULT=80072f8f (e:\nts_sccm_release\sms\framework\osdmessaging\libsmsmessaging.cpp,9410)    TSPxe    26/03/2014 16:37:11    288 (0x0120)
    Failed to get information for MP: http://oursccmserver.ourcompany.com. 80072f8f.    TSPxe    26/03/2014 16:37:11    288 (0x0120)
    Jan Hoedt

    Hi,
    Have you check Mpcontrol.log on the MP server and Smspxe.log?
    Best Regards,
    Joyce Li
    We
    are trying to better understand customer views on social support experience, so your participation in this
    interview project would be greatly appreciated if you have time.
    Thanks for helping make community forums a great place.

  • SCCM 2012R2 OSD PXE-boot-smstftp .var file download times out errorcode 0x00000001- at this point: "Preparing Network" and Reboots

     
    Hello All,
    Please I need help! I have not seen the above error without relationship to two of the  known causes for sometime during a Windows 7 osd in an SCCM 2012 R2 environment with a remote DP/PXE server. I understand this error: to occur when the boot images
    does not have "Network drivers in the past Winpe version ( i.e. 3.0, 4.0), not Winpe 5.0 which has all the Network and storage drivers for Windows 7" or when Port fast is not enabled on the switch port the pxe device is plugged into. These two causes
    stated here have been verified and confirmed not to be the cause in this case within the environment. The PXE boot device has ip-address (verified using ip-config, diskpart as well reveals the disk is online) and can ping the wds/pxe server and the sccm server.
    Port fast is enabled on the switch port the device is plugged into. I am stuck on this one; as I could not ascertain the cause on this occasion. 
    Please see details below and I welcome any help any body can offer, thanks in advance guys!
    Client – Winpe x64
    Server - Windows Server 2008 R2 configured as a PXE / WDS / SCCM DP
    Network - both devices on the same subnet
    Problem: Client performs PXE boot, downloads Winpe without problems.  Client then tries to download .var file.  This is not successful and TFTP timeout is received.  Error code in
    smsts.log states:
    <![LOG[Executing: X:\sms\bin\x64\smstftp.exe -i PXE-Server get \SMSTemp\2014.07.01.14.09.09.0001.{46173825-3EDA-4352-8947-3549830D77A7}.boot.var X:\sms\data\variables.dat]LOG]!><time="14:13:57.285+480"
    date="07-01-2014" component="TSPxe" context="" type="0" thread="376" file="tspxe.cpp:177">
    <![LOG[Command line for extension .exe is "%1" %*]LOG]!><time="14:13:57.332+480" date="07-01-2014" component="TSPxe" context="" type="0"
    thread="376" file="commandline.cpp:228">
    <![LOG[Set command line: "X:\sms\bin\x64\smstftp.exe" -i PXE-Server get \SMSTemp\2014.07.01.14.09.09.0001.{46173825-3EDA-4352-8947-3549830D77A7}.boot.var X:\sms\data\variables.dat]LOG]!><time="14:13:57.332+480"
    date="07-01-2014" component="TSPxe" context="" type="0" thread="376" file="commandline.cpp:731">
    <![LOG[Executing command line: "X:\sms\bin\x64\smstftp.exe" -i PXE-Server get \SMSTemp\2014.07.01.14.09.09.0001.{46173825-3EDA-4352-8947-3549830D77A7}.boot.var X:\sms\data\variables.dat]LOG]!><time="14:13:57.332+480"
    date="07-01-2014" component="TSPxe" context="" type="1" thread="376" file="commandline.cpp:827">
    <![LOG[Process completed with exit code 1]LOG]!><time="14:14:45.379+480" date="07-01-2014" component="TSPxe" context="" type="1" thread="376"
    file="commandline.cpp:1123">
    Network trace is detailed below:
    324994  11:47:35 04/07/2014        166.7634594                      
    Client    Server   AuthIP  AuthIP:version 1.0, Main Mode, Initiator, First Exchange with Unknown peer SPN, Initiator provide proposal Anonymous for negotiation ,Payloads = HDR, CRYPTO, SA, AUTH, Ni, VID, KE, NAT-D, Flags = ..., Length =
    440       {AuthIP:320, UDP:319, IPv4:72}
    325069  11:47:36 04/07/2014        167.7554047       svchost.exe        Client    Server  
    TFTP      TFTP: Read Request - File: \SMSTemp\2014.07.03.15.45.31.0001.{549002A3-C9C9-4189-8AFE-9F8B272BECC1}.boot.var, Transfer Mode: octet                
    {UDP:321, IPv4:72}
    325070  11:47:36 04/07/2014        167.7556504                      
    Client    Server   AuthIP  AuthIP:version 1.0, Main Mode, Initiator, First Exchange with Unknown peer SPN, Initiator provide proposal Anonymous for negotiation ,Payloads = HDR, CRYPTO, SA, AUTH, Ni, VID, KE, NAT-D, Flags = ..., Length =
    440       {AuthIP:320, UDP:319, IPv4:72}
    325071  11:47:36 04/07/2014        167.7598345                      
    Server   Client    TFTP      TFTP: Data - Block Number: 1                {UDP:322, IPv4:72}
    325072  11:47:36 04/07/2014        167.7607151                      
    Client    Server   TFTP      TFTP: Acknowledgement - Block Number: 1          {UDP:322, IPv4:72}
    325073  11:47:36 04/07/2014        167.7608240                      
    Server   Client    TFTP      TFTP: Data - Block Number: 2                {UDP:322, IPv4:72}
    325074  11:47:36 04/07/2014        167.7615948                      
    Client    Server   TFTP      TFTP: Acknowledgement - Block Number: 2          {UDP:322, IPv4:72}
    325075  11:47:36 04/07/2014        167.7616991                      
    Server   Client    TFTP      TFTP: Data - Block Number: 3                {UDP:322, IPv4:72}
    325076  11:47:36 04/07/2014        167.7624602                      
    Client    Server   TFTP      TFTP: Acknowledgement - Block Number: 3          {UDP:322, IPv4:72}
    325077  11:47:36 04/07/2014        167.7625635                      
    Server   Client    TFTP      TFTP: Data - Block Number: 4                {UDP:322, IPv4:72}
    325078  11:47:36 04/07/2014        167.7629426                      
    Client    Server   TFTP      TFTP: Acknowledgement - Block Number: 4          {UDP:322, IPv4:72}
    325079  11:47:36 04/07/2014        167.7630452                      
    Server   Client    TFTP      TFTP: Data - Block Number: 5                {UDP:322, IPv4:72}
    325080  11:47:36 04/07/2014        167.7637927                      
    Client    Server   TFTP      TFTP: Acknowledgement - Block Number: 5          {UDP:322, IPv4:72}
    325081  11:47:36 04/07/2014        167.7638947                      
    Server   Client    TFTP      TFTP: Data - Block Number: 6                {UDP:322, IPv4:72}
    325082  11:47:36 04/07/2014        167.7643324                      
    Client    Server   TFTP      TFTP: Acknowledgement - Block Number: 6          {UDP:322, IPv4:72}
    325083  11:47:36 04/07/2014        167.7644367                      
    Server   Client    TFTP      TFTP: Data - Block Number: 7                {UDP:322, IPv4:72}
    325084  11:47:36 04/07/2014        167.7652140                      
    Client    Server   TFTP      TFTP: Acknowledgement - Block Number: 7          {UDP:322, IPv4:72}
    325085  11:47:36 04/07/2014        167.7653183                      
    Server   Client    TFTP      TFTP: Data - Block Number: 8                {UDP:322, IPv4:72}
    325086  11:47:36 04/07/2014        167.7660907                      
    Client    Server   TFTP      TFTP: Acknowledgement - Block Number: 8          {UDP:322, IPv4:72}
    325087  11:47:36 04/07/2014        167.7661940                      
    Server   Client    TFTP      TFTP: Data - Block Number: 9                {UDP:322, IPv4:72}
    325088  11:47:36 04/07/2014        167.7669372                      
    Client    Server   TFTP      TFTP: Acknowledgement - Block Number: 9          {UDP:322, IPv4:72}
    325089  11:47:36 04/07/2014        167.7670323                      
    Server   Client    TFTP      TFTP: Data - Block Number: 10                {UDP:322, IPv4:72}
    325090  11:47:36 04/07/2014        167.7674067                      
    Client    Server   TFTP      TFTP: Acknowledgement - Block Number: 10        {UDP:322, IPv4:72}
    325091  11:47:36 04/07/2014        167.7674809                      
    Server   Client    TFTP      TFTP: Data - Block Number: 11                {UDP:322, IPv4:72}
    325092  11:47:36 04/07/2014        167.7681308                      
    Client    Server   TFTP      TFTP: Acknowledgement - Block Number: 11        {UDP:322, IPv4:72}
    325093  11:47:36 04/07/2014        167.7682056                      
    Server   Client    TFTP      TFTP: Data - Block Number: 12                {UDP:322, IPv4:72}
    325094  11:47:36 04/07/2014        167.7685383                      
    Client    Server   TFTP      TFTP: Acknowledgement - Block Number: 12        {UDP:322, IPv4:72}
    325095  11:47:36 04/07/2014        167.7686108                      
    Server   Client    TFTP      TFTP: Data - Block Number: 13                {UDP:322, IPv4:72}
    325096  11:47:36 04/07/2014        167.7692475                      
    Client    Server   TFTP      TFTP: Acknowledgement - Block Number: 13        {UDP:322, IPv4:72}
    325097  11:47:36 04/07/2014        167.7693216                      
    Server   Client    TFTP      TFTP: Data - Block Number: 14                {UDP:322, IPv4:72}
    325098  11:47:36 04/07/2014        167.7696477                      
    Client    Server   TFTP      TFTP: Acknowledgement - Block Number: 14        {UDP:322, IPv4:72}
    325099  11:47:36 04/07/2014        167.7697202                      
    Server   Client    TFTP      TFTP: Data - Block Number: 15                {UDP:322, IPv4:72}
    325100  11:47:36 04/07/2014        167.7703651                      
    Client    Server   TFTP      TFTP: Acknowledgement - Block Number: 15        {UDP:322, IPv4:72}
    325101  11:47:36 04/07/2014        167.7704386                      
    Server   Client    TFTP      TFTP: Data - Block Number: 16                {UDP:322, IPv4:72}
    325102  11:47:36 04/07/2014        167.7707479                      
    Client    Server   TFTP      TFTP: Acknowledgement - Block Number: 16        {UDP:322, IPv4:72}
    325103  11:47:36 04/07/2014        167.7708214                      
    Server   Client    TFTP      TFTP: Data - Block Number: 17                {UDP:322, IPv4:72}
    325104  11:47:36 04/07/2014        167.7714862                      
    Client    Server   TFTP      TFTP: Acknowledgement - Block Number: 17        {UDP:322, IPv4:72}
    325105  11:47:36 04/07/2014        167.7715603                      
    Server   Client    TFTP      TFTP: Data - Block Number: 18                {UDP:322, IPv4:72}
    325106  11:47:36 04/07/2014        167.7718715                      
    Client    Server   TFTP      TFTP: Acknowledgement - Block Number: 18        {UDP:322, IPv4:72}
    325107  11:47:36 04/07/2014        167.7719450                      
    Server   Client    TFTP      TFTP: Data - Block Number: 19                {UDP:322, IPv4:72}
    325108  11:47:36 04/07/2014        167.7726029                      
    Client    Server   TFTP      TFTP: Acknowledgement - Block Number: 19        {UDP:322, IPv4:72}
    325109  11:47:36 04/07/2014        167.7726800                      
    Server   Client    TFTP      TFTP: Data - Block Number: 20                {UDP:322, IPv4:72}
    325110  11:47:36 04/07/2014        167.7733471                      
    Client    Server   TFTP      TFTP: Acknowledgement - Block Number: 20        {UDP:322, IPv4:72}
    325111  11:47:36 04/07/2014        167.7734203                      
    Server   Client    TFTP      TFTP: Data - Block Number: 21                {UDP:322, IPv4:72}
    325112  11:47:36 04/07/2014        167.7737411                      
    Client    Server   TFTP      TFTP: Acknowledgement - Block Number: 21        {UDP:322, IPv4:72}
    325113  11:47:36 04/07/2014        167.7738142                      
    Server   Client    TFTP      TFTP: Data - Block Number: 22                {UDP:322, IPv4:72}
    325114  11:47:36 04/07/2014        167.7744648                      
    Client    Server   TFTP      TFTP: Acknowledgement - Block Number: 22        {UDP:322, IPv4:72}
    325115  11:47:36 04/07/2014        167.7745386                      
    Server   Client    TFTP      TFTP: Data - Block Number: 23                {UDP:322, IPv4:72}
    325116  11:47:36 04/07/2014        167.7748657                      
    Client    Server   TFTP      TFTP: Acknowledgement - Block Number: 23        {UDP:322, IPv4:72}
    325117  11:47:36 04/07/2014        167.7749395                      
    Server   Client    TFTP      TFTP: Data - Block Number: 24                {UDP:322, IPv4:72}
    325118  11:47:36 04/07/2014        167.7755914                      
    Client    Server   TFTP      TFTP: Acknowledgement - Block Number: 24        {UDP:322, IPv4:72}
    325119  11:47:36 04/07/2014        167.7756649                      
    Server   Client    TFTP      TFTP: Data - Block Number: 25                {UDP:322, IPv4:72}
    325120  11:47:36 04/07/2014        167.7760109                      
    Client    Server   TFTP      TFTP: Acknowledgement - Block Number: 25        {UDP:322, IPv4:72}
    325277  11:47:37 04/07/2014        168.7554246                      
    Client    Server   AuthIP  AuthIP:version 1.0, Main Mode, Initiator, First Exchange with Unknown peer SPN, Initiator provide proposal Anonymous for negotiation ,Payloads = HDR, CRYPTO, SA, AUTH, Ni, VID, KE, NAT-D, Flags = ..., Length =
    440       {AuthIP:320, UDP:319, IPv4:72}
    325278  11:47:37 04/07/2014        168.7709396                      
    Client    Server   TFTP      TFTP: Acknowledgement - Block Number: 25        {UDP:322, IPv4:72}
    325397  11:47:39 04/07/2014        170.7708892                      
    Client    Server   TFTP      TFTP: Acknowledgement - Block Number: 25        {UDP:322, IPv4:72}
    326185  11:47:40 04/07/2014        171.7552905                      
    Client    Server   AuthIP  AuthIP:version 1.0, Main Mode, Initiator, First Exchange with Unknown peer SPN, Initiator provide proposal Anonymous for negotiation ,Payloads = HDR, CRYPTO, SA, AUTH, Ni, VID, KE, NAT-D, Flags = ..., Length =
    440       {AuthIP:320, UDP:319, IPv4:72}
    327030  11:47:43 04/07/2014        174.7588879                      
    Client    Server   AuthIP  AuthIP:version 1.0, Main Mode, Initiator, First Exchange with Unknown peer SPN, Initiator provide proposal Anonymous for negotiation ,Payloads = HDR, CRYPTO, SA, AUTH, Ni, VID, KE, NAT-D, Flags = ..., Length =
    440       {AuthIP:419, UDP:319, IPv4:72}
    327031  11:47:43 04/07/2014        174.7707730                      
    Client    Server   TFTP      TFTP: Acknowledgement - Block Number: 25        {UDP:322, IPv4:72}
    327178  11:47:44 04/07/2014        175.7552028                      
    Client    Server   AuthIP  AuthIP:version 1.0, Main Mode, Initiator, First Exchange with Unknown peer SPN, Initiator provide proposal Anonymous for negotiation ,Payloads = HDR, CRYPTO, SA, AUTH, Ni, VID, KE, NAT-D, Flags = ..., Length =
    440       {AuthIP:419, UDP:319, IPv4:72}
    327510  11:47:45 04/07/2014        176.7551962                      
    Client    Server   AuthIP  AuthIP:version 1.0, Main Mode, Initiator, First Exchange with Unknown peer SPN, Initiator provide proposal Anonymous for negotiation ,Payloads = HDR, CRYPTO, SA, AUTH, Ni, VID, KE, NAT-D, Flags = ..., Length =
    440       {AuthIP:419, UDP:319, IPv4:72}
    328598  11:47:48 04/07/2014        179.7552497                      
    Client    Server   AuthIP  AuthIP:version 1.0, Main Mode, Initiator, First Exchange with Unknown peer SPN, Initiator provide proposal Anonymous for negotiation ,Payloads = HDR, CRYPTO, SA, AUTH, Ni, VID, KE, NAT-D, Flags = ..., Length =
    440       {AuthIP:419, UDP:319, IPv4:72}
    328630  11:47:51 04/07/2014        182.7551309                      
    Client    Server   AuthIP  AuthIP:version 1.0, Main Mode, Initiator, First Exchange with Unknown peer SPN, Initiator provide proposal Anonymous for negotiation ,Payloads = HDR, CRYPTO, SA, AUTH, Ni, VID, KE, NAT-D, Flags = ..., Length =
    440       {AuthIP:419, UDP:319, IPv4:72}
    328631  11:47:51 04/07/2014        182.7707620                      
    Client    Server   TFTP      TFTP: Acknowledgement - Block Number: 25        {UDP:322, IPv4:72}
    328658  11:47:54 04/07/2014        185.7550375                      
    Client    Server   AuthIP  AuthIP:version 1.0, Main Mode, Initiator, First Exchange with Unknown peer SPN, Initiator provide proposal Anonymous for negotiation ,Payloads = HDR, CRYPTO, SA, AUTH, Ni, VID, KE, NAT-D, Flags = ..., Length =
    440       {AuthIP:419, UDP:319, IPv4:72}
    328669  11:47:57 04/07/2014        188.7709719                      
    Client    Server   AuthIP  AuthIP:version 1.0, Main Mode, Initiator, First Exchange with Unknown peer SPN, Initiator provide proposal Anonymous for negotiation ,Payloads = HDR, CRYPTO, SA, AUTH, Ni, VID, KE, NAT-D, Flags = ..., Length =
    440       {AuthIP:419, UDP:319, IPv4:72}
    328677  11:47:59 04/07/2014        190.7862445                      
    Client    Server   TFTP      TFTP: Acknowledgement - Block Number: 25        {UDP:322, IPv4:72}
    328690  11:48:00 04/07/2014        191.7708666                      
    Client    Server   AuthIP  AuthIP:version 1.0, Main Mode, Initiator, First Exchange with Unknown peer SPN, Initiator provide proposal Anonymous for negotiation ,Payloads = HDR, CRYPTO, SA, AUTH, Ni, VID, KE, NAT-D, Flags = ..., Length =
    440       {AuthIP:419, UDP:319, IPv4:72}
    328717  11:48:03 04/07/2014        194.7706918                      
    Client    Server   AuthIP  AuthIP:version 1.0, Main Mode, Initiator, First Exchange with Unknown peer SPN, Initiator provide proposal Anonymous for negotiation ,Payloads = HDR, CRYPTO, SA, AUTH, Ni, VID, KE, NAT-D, Flags = ..., Length =
    440       {AuthIP:419, UDP:319, IPv4:72}
    328730  11:48:06 04/07/2014        197.7704623                      
    Client    Server   AuthIP  AuthIP:version 1.0, Main Mode, Initiator, First Exchange with Unknown peer SPN, Initiator provide proposal Anonymous for negotiation ,Payloads = HDR, CRYPTO, SA, AUTH, Ni, VID, KE, NAT-D, Flags = ..., Length =
    440       {AuthIP:419, UDP:319, IPv4:72}
    328736  11:48:07 04/07/2014        198.7861669                      
    Client    Server   TFTP      TFTP: Acknowledgement - Block Number: 25        {UDP:322, IPv4:72}
    329217  11:48:09 04/07/2014        200.7705229                      
    Client    Server   AuthIP  AuthIP:version 1.0, Main Mode, Initiator, First Exchange with Unknown peer SPN, Initiator provide proposal Anonymous for negotiation ,Payloads = HDR, CRYPTO, SA, AUTH, Ni, VID, KE, NAT-D, Flags = ..., Length =
    440       {AuthIP:419, UDP:319, IPv4:72}
    329420  11:48:12 04/07/2014        203.7704633                      
    Client    Server   AuthIP  AuthIP:version 1.0, Main Mode, Initiator, First Exchange with Unknown peer SPN, Initiator provide proposal Anonymous for negotiation ,Payloads = HDR, CRYPTO, SA, AUTH, Ni, VID, KE, NAT-D, Flags = ..., Length =
    440       {AuthIP:419, UDP:319, IPv4:72}
    329795  11:48:15 04/07/2014        206.7704298                      
    Client    Server   AuthIP  AuthIP:version 1.0, Main Mode, Initiator, First Exchange with Unknown peer SPN, Initiator provide proposal Anonymous for negotiation ,Payloads = HDR, CRYPTO, SA, AUTH, Ni, VID, KE, NAT-D, Flags = ..., Length =
    440       {AuthIP:419, UDP:319, IPv4:72}
    329796  11:48:15 04/07/2014        206.7858646                      
    Client    Server   TFTP      TFTP: Acknowledgement - Block Number: 25        {UDP:322, IPv4:72}
    329990  11:48:18 04/07/2014        209.7704360                      
    Client    Server   AuthIP  AuthIP:version 1.0, Main Mode, Initiator, First Exchange with Unknown peer SPN, Initiator provide proposal Anonymous for negotiation ,Payloads = HDR, CRYPTO, SA, AUTH, Ni, VID, KE, NAT-D, Flags = ..., Length =
    440       {AuthIP:419, UDP:319, IPv4:72}
    330005  11:48:21 04/07/2014        212.7703291                      
    Client    Server   AuthIP  AuthIP:version 1.0, Main Mode, Initiator, First Exchange with Unknown peer SPN, Initiator provide proposal Anonymous for negotiation ,Payloads = HDR, CRYPTO, SA, AUTH, Ni, VID, KE, NAT-D, Flags = ..., Length =
    440       {AuthIP:419, UDP:319, IPv4:72}
    330014  11:48:23 04/07/2014        214.7862410                      
    Client    Server   TFTP      TFTP: Error - ErrorCode: 0, ErrorMessage: timeout on receive           {UDP:322, IPv4:72}

    Hi,
    According to the logs, this issue still should be related to network driver. It failed after network driver initialized. Please try to use another network driver.
    Best Regards,
    Joyce
    We
    are trying to better understand customer views on social support experience, so your participation in this
    interview project would be greatly appreciated if you have time.
    Thanks for helping make community forums a great place.

  • Policy retreiving for client that is pxe booting

    Wanna ask, to which management point server does a client will retrieve its policy prior to executing the TS? Does it based on the ip address boundary range?
    Which logfile I can see to reoubleshoot client pxe issue? is it smspxe.log?

    Short answer is:  it doesn't.  But we have to break down what's happening.
    Remember when you PXE boot you are actually operating at Layer 2 still, and the WDS services are answering a broadcast.  So no MP enters the picture before a TS runs _at_all_, instead it's the Distribution Point (which controls the WDS/PXE services
    in 2012) that is connecting to the client and providing the TS.
    You can actually see this happening on the SMSPXE.log (I'm going from memory on the log name, sorry if i got it wrong) in the SMS_DP$\sms\logs when the PXE servive gets the mac, matches it against the DB then provides the TS available.
    Again we are basically doing this at layer 2, even though the client will eventually get an IP and use said IP to TFTP download said image... 
    More depth here:
    http://blogs.technet.com/b/pingpawan/archive/2014/01/12/deep-dive-pxe-boot-flow-for-sccm-2007-2012.aspx
    EDIT:  to speculate on your question a bit: so if there are multiple DPs in the same subnet, or there is possibly IPHelper in the picture in some way ... the DP that answers is basically random unless a response delay is set (can be done on the DP in
    in the MMC).

  • PXE boot OSD connects to Internet-only Management Point. A bug?

    So here is the deal: SCCM registers the Management Points to be used in DPs PXE in a Registry file, it is done in alphabetical order (or install order), so all PXE boots will always connect to the first MP (Microsoft, WTF?). In my case, the first is an INTERNET
    ONLY MP, why would PXE Booted OSD connect to that? Brrr..
    Solution is to edit the registry, put the MPs in the right order and then it works like a charm.. until some SCCM maintenance task overwrites it with the default MP list, including internet only MP as first.
    MPs don't respect boundaries and I cannot just block the ports (OSD will be slow, it first tries to connect to the internet MP, times out, then uses the next one).
    A) This behaviour is a bug. PXE Boot should NEVER connect to Internet Only MP (OSD is not supported for IBCM).
    B) Does anybody know what maintenance overwrites the DPs registry key "ManagementPoints"?
    I cannot just use one MP. All external MPs are configured for internet only, internal MPs are configured intranet only. 
    Ideas?

    The distribution manager on the site server is the component that populates the MP list on the registry of DP/PXE.
    Dist mgr currently writes all the MPs and does not filter-out the internet-facing MPs.
    Even if you manually edit the registry on the DP, dist mgr will over-write it the next time it updates the DP. You can try to put an ACL on the registry key which prevents the site server from updating it. However, the DP will never get updated by the site
    for other things.

  • Creating new OSD task sequence causes PXE boot to fail

    I'm running SCCM 2012 on Server 2008 R2. Currently we have a standard task sequence we use for all of our Windows 7 deployments that is working fine. We use PXE boot to load up WinPE to select the task sequence to load and all is good.
    I've made a new task sequence to deploy custom configuration settings to a group of computers. I've duplicated much of the original task sequence, using the same boot media. After i deploy the new TS to the All Unknown Computers collection, PXE boot does
    not work anymore.
    It downloads WDSNBP, starts by DHCP referral, contacts the server. After that I just get a Pending Request ID: number says contacting server then fails. If i go back to my new TS and delete the deployment, all is good again.
    Can i create a new task sequence using an existing reference image? Has anyone seen this type of issue before? I see similar issues online, but it seems to be for people that cannot PXE boot at all. My problem is just that the new task sequence seems to
    kill PXE boot when it's deployed.

    This is from the log file, looks like it can't find the boot image. I'm using the same boot image for both of the task sequences though.
    <![LOG[Set media certificate in transport]LOG]!><time="11:35:45.257+300" date="02-20-2014" component="SMSPXE" context="" type="1" thread="4532" file="libsmsmessaging.cpp:9220">
    <![LOG[Set authenticator in transport]LOG]!><time="11:35:45.257+300" date="02-20-2014" component="SMSPXE" context="" type="1" thread="4532" file="libsmsmessaging.cpp:7592">
    <![LOG[Set authenticator in transport]LOG]!><time="11:35:45.301+300" date="02-20-2014" component="SMSPXE" context="" type="1" thread="4532" file="libsmsmessaging.cpp:7592">
    <![LOG[Client lookup reply: <ClientIDReply><Identification Unknown="0" ItemKey="0" ServerName="" ServerRemoteName=""><Machine><ClientID/><NetbiosName/></Machine></Identification></ClientIDReply>
    ]LOG]!><time="11:35:45.359+300" date="02-20-2014" component="SMSPXE" context="" type="1" thread="4532" file="libsmsmessaging.cpp:6204">
    <![LOG[Set media certificate in transport]LOG]!><time="11:35:45.419+300" date="02-20-2014" component="SMSPXE" context="" type="1" thread="4532" file="libsmsmessaging.cpp:9220">
    <![LOG[Set authenticator in transport]LOG]!><time="11:35:45.420+300" date="02-20-2014" component="SMSPXE" context="" type="1" thread="4532" file="libsmsmessaging.cpp:7592">
    <![LOG[Set authenticator in transport]LOG]!><time="11:35:45.455+300" date="02-20-2014" component="SMSPXE" context="" type="1" thread="4532" file="libsmsmessaging.cpp:7592">
    <![LOG[PXE::CBootImageManager::FindMatchingArchitectureBootImage]LOG]!><time="11:35:45.508+300" date="02-20-2014" component="SMSPXE" context="" type="1" thread="4532" file="bootimagemgr.cpp:1736">
    <![LOG[Getting boot action for unknown machine: item key: 2046820353]LOG]!><time="11:35:45.572+300" date="02-20-2014" component="SMSPXE" context="" type="1" thread="4532" file="pxehandler.cpp:226">
    <![LOG[Set media certificate in transport]LOG]!><time="11:35:45.637+300" date="02-20-2014" component="SMSPXE" context="" type="1" thread="4532" file="libsmsmessaging.cpp:9220">
    <![LOG[Set authenticator in transport]LOG]!><time="11:35:45.637+300" date="02-20-2014" component="SMSPXE" context="" type="1" thread="4532" file="libsmsmessaging.cpp:7592">
    <![LOG[Set authenticator in transport]LOG]!><time="11:35:45.678+300" date="02-20-2014" component="SMSPXE" context="" type="1" thread="4532" file="libsmsmessaging.cpp:7592">
    <![LOG[Client boot action reply: <ClientIDReply><Identification Unknown="0" ItemKey="2046820353" ServerName="" ServerRemoteName=""><Machine><ClientID>44f40eda-b0b0-44ae-87e1-9b9464046c39</ClientID><NetbiosName/></Machine></Identification><PXEBootAction
    LastPXEAdvertisementID="" LastPXEAdvertisementTime="" OfferID="COL20062" OfferIDTime="20/02/2014 11:22:00 AM" PkgID="COL00086" PackageVersion="" PackagePath="http://TECH-SVR2.county-lambton.on.ca/SMS_DP_SMSPKG$/COL00045" BootImageID="COL00045" Mandatory="0"/></ClientIDReply>
    ]LOG]!><time="11:35:45.743+300" date="02-20-2014" component="SMSPXE" context="" type="1" thread="4532" file="libsmsmessaging.cpp:6402">
    <![LOG[Client Identity: 9ca0acb3-06b1-4737-9db0-1e4b75336ec9]LOG]!><time="11:35:45.743+300" date="02-20-2014" component="SMSPXE" context="" type="1" thread="4532" file="libsmsmessaging.cpp:6428">
    <![LOG[PXE::CBootImageManager::FindMatchingArchitectureBootImage]LOG]!><time="11:35:45.743+300" date="02-20-2014" component="SMSPXE" context="" type="1" thread="4532" file="bootimagemgr.cpp:1736">
    <![LOG[PXE::CBootImageManager::FindBootImage: COL00045]LOG]!><time="11:35:45.743+300" date="02-20-2014" component="SMSPXE" context="" type="1" thread="4532" file="bootimagemgr.cpp:1652">
    <![LOG[Looking for bootImage COL00045]LOG]!><time="11:35:45.743+300" date="02-20-2014" component="SMSPXE" context="" type="1" thread="4532" file="bootimagemgr.cpp:1686">
    <![LOG[PXE::CBootImageCache::FindImage]LOG]!><time="11:35:45.743+300" date="02-20-2014" component="SMSPXE" context="" type="1" thread="4532" file="bootimagecache.cpp:657">
    <![LOG[MAC=9C:B6:54:A3:53:19 SMBIOS GUID=70DCD781-5008-11E4-8264-8BD5B90C0061 > Could not find an available image BootImageID=COL00045]LOG]!><time="11:35:45.743+300" date="02-20-2014" component="SMSPXE" context="" type="1" thread="4532" file="pxehandler.cpp:2095">
    <![LOG[PXE::CBootImageManager::FindMatchingArchitectureBootImage]LOG]!><time="11:36:05.335+300" date="02-20-2014" component="SMSPXE" context="" type="1" thread="4532" file="bootimagemgr.cpp:1736">
    <![LOG[PXE::CBootImageManager::FindBootImage: COL00045]LOG]!><time="11:36:05.335+300" date="02-20-2014" component="SMSPXE" context="" type="1" thread="4532" file="bootimagemgr.cpp:1652">
    <![LOG[Looking for bootImage COL00045]LOG]!><time="11:36:05.335+300" date="02-20-2014" component="SMSPXE" context="" type="1" thread="4532" file="bootimagemgr.cpp:1686">
    <![LOG[PXE::CBootImageCache::FindImage]LOG]!><time="11:36:05.335+300" date="02-20-2014" component="SMSPXE" context="" type="1" thread="4532" file="bootimagecache.cpp:657">

  • OSD to Surface fails to PXE Boot and returns PXEGetPXEData Failed with 0x80004005

    Scenario: When trying to Image Windows 8.1 to a Surface Pro, Surface Pro 2 and Surface Pro 3 I have downloaded the latest Surface Firmware and Drivers (August 18th 2014 I believe), the NIC's are in the x64 PXE Boot Image. I have verified that no DHCP Option
    67 is set, and that SpanningTree PortFast is enabled. All other Images function correctly, Windows 7 Sp1 works. We use the Microsoft USB NIC, and we PXE boot and download the PXE Image fine, then it comes into windows and goes to detect the NIC, at which point
    it fails and reboots.
    The Surface has had Firmware update on it to the latest.
    It appears the NIC just stops working, which makes me think that the latest Driver pack for Surface does not contain the PXE boot versions for their NIC.
    Trying the Docking Station (which utilizes NIC ASIX AX888772) exhibits the same problem.
    The NIC stays active until the OSD Screen comes up, it fails trying to load the Surface NIC though (or the NICs in the Driver pack they just released do not include a PXE Boot Driver...the Drivers once imported do not show any as being Boot Critical...which
    make me think this is the case even more so.
    Doing a USB PXE Boot also fails to load the NIC.
    Going to F8 and doing IPCONFIG /RENEW verifies the NIC is not active.
    I see tons of postings on the Surface being a nightmare to image.
    Errors:
    Failed to Download pxe variable file. Code (0x0000001)
    PXEGetPXEData Failed with 0x80004005
    Anybody having any other experiences out there, or have anything else they could think to try?
    David Baur

    (or the NICs in the Driver pack they just released do not include a PXE Boot Driver...the Drivers once imported do not show any as being Boot Critical...which make me think this is the case even more so.
    There are no "PXE boot versions" of drivers at all. What you described just indicates that there is no driver in winpe that matches the hardware. WinPe is based on the respective version of the full os so you have to add Win8.x drivers to the boot image.
    The architecture also has to match. Have you added NIC drivers to the boot image at all?
    NIC drivers are never boot critical if I am not mistaken.
    Torsten Meringer | http://www.mssccmfaq.de

  • Restrict OSD to PXE boot only

    In my environment we wish to only use PXE boot for imaging machines.  Is there a conditional check I can add to a task sequence that will cause it to abort if it's not run from a PXE boot?  I guess what I'm shooting for is a fail-safe that will
    prevent someone from accidentally deploying a task sequence to a collection of computers thus wiping them out.  I would hate for someone to wipe out the entire infrastructure.  I know when you deploy the task sequence there are options that define
    where and how to deploy a task sequence, but what if someone accidentally clicks the wrong option (i.e. config client)?  I would appreciate any suggestions.  Thanks in advance...

    A very simplistic method would be to set a task sequence variable (for example StartedInWinPE) to true, as the first step in the task sequence, when the task sequence was started in WinPE (use the buildin variable _SMSTSInWinPE for that
    check). Then add the rest of the task sequence in a group and use the StartedInWinPE variable as a check to start the group. That way the rest of the task sequence will only run when it was started in WinPE.
    My Blog: http://www.petervanderwoude.nl/
    Follow me on twitter: pvanderwoude

  • "Welcome to the Task Sequence Wizard" never shows on PXE boot, but does on Boot Media with prestart command

    Hey guys, I have a fairly odd situation here.  I have all OSD Task Sequence advertisements set to "PXE and Boot Media (hidden)" and all are optional
    (not mandatory).  I use a powershell form via prestart command to give the user a choice which limits what task sequences they choose.  When everything is working, this process works.  Unknown desktop-class systems see desktop task sequences,
    and server-class systems see server task sequences.
    Here's where it's different when I use different boot methods:
    Boot Media
    "Welcome to the Task Sequence Wizard" is presented.  User hits or clicks Enter.
    Powershell form is presented; user picks their task sequence
    Confirmation screen is presented with the task sequence they selected (this is an OSD screen the same size as the "Welcome to the Task Sequence Wizard"
    screen.
    Dependency check screen is shown with a progress bar.  If a package is missing from a DP, it will display an error here with the PackageID.  This
    looks the same as "Regular" OSD with standard non-hidden advertisements.
    PXE Boot
    "Welcome to the Task Sequence Wizard" is never displayed.
    Powershell form is the first screen they see.  They select it and it continues.
    No confirmation screen is presented if the system is known;  if it is an unknown system, a small dialog says there is a
    *mandatory* task sequence about to be run and it will run in 180 seconds.  Users can hit enter.
    No dependency check screen is shown; and if a package was missing, instead of presenting an error, it simply reboots.  However, if everything is there,
    the process starts successfully.
    While I have no problems with the first window never being displayed, not displaying the error dialog and simply rebooting is what is bothersome to me. 
    99% of our builds are from PXE boot.
    Again, these task sequences are all 100% optional, NOT mandatory, and I've double checked this multiple times.  Can anyone explain why we get different
    behavior between boot media and PXE boot?  Any way of getting PXE boot to "mimic" the Boot media behavior?
    I followed the guide here:
    http://www.mydreampage.net/2012/09/21/how-can-i-deploy-a-hidden-task-sequence-in-configuration-manager-2012-sp1/
    If you see the image here:
    http://www.windows-noob.com/forums/uploads/monthly_09_2012/post-1-0-29840100-1348236179.png
    You'll see the "Retrieving policy for this computer..." dialog box - I never get that with PXE - just Boot Media.
    Note that I am running 2012 R2, not 2012 SP1 - but I never got a chance to test this process with SP1.
    Upon further experimentation, the "hidden" task sequence has nothing to do with this.  If I change it to a normal, non-hidden advertisement, as
    long as the "prestart" command in the boot image is used, we don't get those missing dialog boxes at all, with PXE.

    Are both boot images the same for PXE and the boot media? Same package ID and all? 
    Boot media for us always shows the task sequence wizard first, while PXE always displays the pre-start command first. 
    Daniel Ratliff | http://www.PotentEngineer.com

  • Slow PXE boot. TFTP windowing issue

    Hi
    we have just set up SCCM 2012 and have configured OSD. It works well apart form the length of time it takes to download the boot.wim on a PXE boot. 
    We took some network traces and noticed that TFTP was behaving as if the Windowing was set to 1 so every block was being ACK'ed before another was sent.
    I checked the Windowing size on the bcd file of the boot image and the setting was
    ramdisktftpwindowsize   4
    Any ideas why TFTP doesn;t seem to be picking this up?

    The Microsoft article would suggest that the Window Size options should be available in the latest implementations of PXE
    http://technet.microsoft.com/en-us/library/hh974416.aspx
    TFTP enhancements
    What value does this change add?
    Trivial File Transfer Protocol (TFTP) enhancements result in improved performance.
    What works differently?
    TFTP (Trivial File Transfer Protocol) has been enhanced and delivers improved results in performance.
    You use the Windows Deployment Services Trivial File Transfer Protocol (TFTP) server to download the files
    that are needed to do a network boot using the Pre-Boot Execution Environment (PXE). PXE technology is a standard created by Intel that establishes a common and consistent set of pre-boot services within the boot firmware. The end goal is to enable a client
    to do a network boot and receive a network boot program (NBP) from a network boot server.
    TFTP enhancements include:
    Scalable buffer management Provides
    support for a shared client buffer; allows buffering an entire file instead of a fixed size buffer for each client. Scalable TFTP buffer feature allows maintaining a single buffer per file in the server. When the server is buffering a file in shared mode,
    different sessions can read from the same shared buffer.
    Scalable port management Ability
    to use a dynamic or a fixed range of UDP ports to service clients with shared UDP port allocation. Sharing the same server port among different TFTP sessions improves scalability because there are sufficient ports when more clients are actively using the server.
    Variable-size transmission window Allows
    the client and server to determine the largest workable window size, resulting in improved TFTP performance. Provides the ability to dynamically determine the optimal window size.
    Maximum TFTP block size Previously implemented
    as a registry setting, this is now exposed to users through WDSUTIL and the WDS MMC snap-in.

  • PXE boot fails and reboots after loading PE

    I have run into what I think is a unique issue and need some help determining the cause.
    We are in the process of replacing and aging DP/PXE point (2003 R2 SP2) with a new server (2008 STD R2 SP1).  What makes my pxe issue unique is that pxe works without issue on the existing 2003 DP/PXE server.  But on the new 2008 server I run into
    the following issue.
    Environment:  Config Manager 2007 R2, a single primary, multiple DP's and PXE points.
    Issue:  When I attempt to PXE boot a system, I am able to load PE, but shortly after the custom background screen is loaded, the system reboots.  I've searched the internet quite a bit and found lots of potential causes including, bad/missing drivers,
    certificate issues, rights issues, etc.  None of these seem to be the cause.
    My troubleshooting has determined that the client computers are unable to download the variables.dat file.  I just don't know why.
    We're using the same boot images on both servers. 
    I've tried using multiple computer models and VM's. 
    I've opened a command prompt as soon as our background image loads and have verified that the system is pulling a valid IP address.  I am able to map a drive to the PXE server's REMINST share using our sccm net access account and manually copy the .var
    file using xcopy to the appropriate directory on the local virtual drive.   I've also attempted to manually run smstftp.exe by mimicking the command line from the smsts log file.  I'll admit that I'm not sure I have the correct syntax for smstftp. 
    I've tried several variations and all but one result in a short pause and no file copied/created in the X:\sms\data folder.  The one that does produce a result says that the file cannot be found.  I checked for typos and made sure I used the name
    of the newly created .var file.
    I've also tried disabling anti-virus on the server, shutting off the windows firewall on the server, granting everyone read rights to the REMINST share.
    Below is the smstslog file I've been using as a reference.  Per corporate security policy, I have X'd out the IP address of the PXE server.  The log file for the successful pxe boot from the 2003 server shows an exit code of 0 for smstftp.exe, a note
    about successful download of the pxe var file and then it continues through the rest of the boot process.
    -----SMSTS log file from a failed PXE boot on the new 2008 server -----
    <![LOG[LOGGING: Finalize process ID set to 832]LOG]!><time="16:13:54.440+000" date="12-23-2013" component="TSBootShell" context="" type="1" thread="836" file="tslogging.cpp:1489">
    <![LOG[==============================[ TSBootShell.exe ]==============================]LOG]!><time="16:13:54.440+000" date="12-23-2013" component="TSBootShell" context="" type="1" thread="836"
    file="bootshell.cpp:963">
    <![LOG[Succeeded loading resource DLL 'X:\sms\bin\i386\1033\TSRES.DLL']LOG]!><time="16:13:54.440+000" date="12-23-2013" component="TSBootShell" context="" type="1" thread="836" file="util.cpp:869">
    <![LOG[Debug shell is enabled]LOG]!><time="16:13:54.440+000" date="12-23-2013" component="TSBootShell" context="" type="1" thread="836" file="bootshell.cpp:974">
    <![LOG[Waiting for PNP initialization...]LOG]!><time="16:13:54.471+000" date="12-23-2013" component="TSBootShell" context="" type="1" thread="880" file="bootshell.cpp:59">
    <![LOG[Booted from network (PXE)]LOG]!><time="16:13:54.830+000" date="12-23-2013" component="TSBootShell" context="" type="1" thread="880" file="configpath.cpp:198">
    <![LOG[Found config path X:\sms\data\]LOG]!><time="16:13:54.830+000" date="12-23-2013" component="TSBootShell" context="" type="1" thread="880" file="bootshell.cpp:553">
    <![LOG[Booting from removable media, not restoring bootloaders on hard drive]LOG]!><time="16:13:54.830+000" date="12-23-2013" component="TSBootShell" context="" type="1" thread="880" file="bootshell.cpp:564">
    <![LOG[Executing command line: wpeinit.exe -winpe]LOG]!><time="16:13:54.830+000" date="12-23-2013" component="TSBootShell" context="" type="1" thread="880" file="bootshell.cpp:767">
    <![LOG[Executing command line: X:\WINDOWS\system32\cmd.exe /k]LOG]!><time="16:13:57.014+000" date="12-23-2013" component="TSBootShell" context="" type="1" thread="836" file="bootshell.cpp:767">
    <![LOG[The command completed successfully.]LOG]!><time="16:13:57.014+000" date="12-23-2013" component="TSBootShell" context="" type="1" thread="836" file="bootshell.cpp:850">
    <![LOG[Successfully launched command shell.]LOG]!><time="16:13:57.014+000" date="12-23-2013" component="TSBootShell" context="" type="1" thread="836" file="bootshell.cpp:430">
    <![LOG[The command completed successfully.]LOG]!><time="16:14:41.458+000" date="12-23-2013" component="TSBootShell" context="" type="1" thread="880" file="bootshell.cpp:850">
    <![LOG[Starting DNS client service.]LOG]!><time="16:14:41.458+000" date="12-23-2013" component="TSBootShell" context="" type="1" thread="880" file="bootshell.cpp:597">
    <![LOG[Executing command line: X:\sms\bin\i386\TsmBootstrap.exe /env:WinPE /configpath:X:\sms\data\]LOG]!><time="16:14:41.973+000" date="12-23-2013" component="TSBootShell" context="" type="1" thread="880"
    file="bootshell.cpp:767">
    <![LOG[The command completed successfully.]LOG]!><time="16:14:41.973+000" date="12-23-2013" component="TSBootShell" context="" type="1" thread="880" file="bootshell.cpp:850">
    <![LOG[==============================[ TSMBootStrap.exe ]==============================]LOG]!><time="16:14:41.989+000" date="12-23-2013" component="TSMBootstrap" context="" type="1" thread="1932"
    file="tsmbootstrap.cpp:1039">
    <![LOG[Command line: X:\sms\bin\i386\TsmBootstrap.exe /env:WinPE /configpath:X:\sms\data\]LOG]!><time="16:14:41.989+000" date="12-23-2013" component="TSMBootstrap" context="" type="0" thread="1932"
    file="tsmbootstrap.cpp:1040">
    <![LOG[Succeeded loading resource DLL 'X:\sms\bin\i386\1033\TSRES.DLL']LOG]!><time="16:14:41.989+000" date="12-23-2013" component="TSMBootstrap" context="" type="1" thread="1932" file="util.cpp:869">
    <![LOG[Succeeded loading resource DLL 'X:\sms\bin\i386\TSRESNLC.DLL']LOG]!><time="16:14:41.989+000" date="12-23-2013" component="TSMBootstrap" context="" type="1" thread="1932" file="resourceutils.cpp:152">
    <![LOG[Processor Is IA64: 0]LOG]!><time="16:14:41.989+000" date="12-23-2013" component="TSMBootstrap" context="" type="1" thread="1932" file="tsmbootstrap.cpp:1005">
    <![LOG[PXE Boot with Root = X:\]LOG]!><time="16:14:41.989+000" date="12-23-2013" component="TSMBootstrap" context="" type="1" thread="1932" file="tsmbootstrap.cpp:921">
    <![LOG[Executing from PXE in WinPE]LOG]!><time="16:14:41.989+000" date="12-23-2013" component="TSMBootstrap" context="" type="0" thread="1932" file="tsmbootstrap.cpp:936">
    <![LOG[Loading TsPxe.dll from X:\sms\bin\i386\TsPxe.dll]LOG]!><time="16:14:41.989+000" date="12-23-2013" component="TSMBootstrap" context="" type="0" thread="1932" file="tsmbootstraputil.cpp:1319">
    <![LOG[TsPxe.dll loaded]LOG]!><time="16:14:42.004+000" date="12-23-2013" component="TSPxe" context="" type="0" thread="1932" file="tsmbootstraputil.cpp:1329">
    <![LOG[Device has PXE booted]LOG]!><time="16:14:42.004+000" date="12-23-2013" component="TSPxe" context="" type="0" thread="1932" file="tspxe.cpp:122">
    <![LOG[Variable Path: \SMSTemp\2013.12.23.16.11.24.0002.{AB0FBE86-1F6C-47D7-919B-A44641035A2E}.boot.var]LOG]!><time="16:14:42.004+000" date="12-23-2013" component="TSPxe" context="" type="0" thread="1932"
    file="tspxe.cpp:134">
    <![LOG[Variable Key Len: 61]LOG]!><time="16:14:42.004+000" date="12-23-2013" component="TSPxe" context="" type="0" thread="1932" file="tspxe.cpp:141">
    <![LOG[Succesfully added firewall rule for Tftp]LOG]!><time="16:14:42.004+000" date="12-23-2013" component="TSPxe" context="" type="0" thread="1932" file="fwopen.cpp:123">
    <![LOG[Executing: X:\sms\bin\i386\smstftp.exe -i XXX.XXX.XXX.XXX get \SMSTemp\2013.12.23.16.11.24.0002.{AB0FBE86-1F6C-47D7-919B-A44641035A2E}.boot.var X:\sms\data\variables.dat]LOG]!><time="16:14:42.004+000" date="12-23-2013"
    component="TSPxe" context="" type="0" thread="1932" file="tspxe.cpp:177">
    <![LOG[Command line for extension .exe is "%1" %*]LOG]!><time="16:14:42.067+000" date="12-23-2013" component="TSPxe" context="" type="0" thread="1932" file="commandline.cpp:229">
    <![LOG[Set command line: "X:\sms\bin\i386\smstftp.exe" -i XXX.XXX.XXX.XXX get \SMSTemp\2013.12.23.16.11.24.0002.{AB0FBE86-1F6C-47D7-919B-A44641035A2E}.boot.var X:\sms\data\variables.dat]LOG]!><time="16:14:42.067+000" date="12-23-2013"
    component="TSPxe" context="" type="0" thread="1932" file="commandline.cpp:707">
    <![LOG[Executing command line: "X:\sms\bin\i386\smstftp.exe" -i XXX.XXX.XXX.XXX get \SMSTemp\2013.12.23.16.11.24.0002.{AB0FBE86-1F6C-47D7-919B-A44641035A2E}.boot.var X:\sms\data\variables.dat]LOG]!><time="16:14:42.067+000" date="12-23-2013"
    component="TSPxe" context="" type="1" thread="1932" file="commandline.cpp:805">
    <![LOG[Process completed with exit code 1]LOG]!><time="16:15:29.179+000" date="12-23-2013" component="TSPxe" context="" type="1" thread="1932" file="commandline.cpp:1102">
    <![LOG[Succesfully removed firewall rule for Tftp]LOG]!><time="16:15:29.194+000" date="12-23-2013" component="TSPxe" context="" type="0" thread="1932" file="fwopen.cpp:146">
    <![LOG[uExitCode == 0, HRESULT=80004005 (e:\nts_sms_fre\sms\server\pxe\tspxe\tspxe.cpp,185)]LOG]!><time="16:15:29.194+000" date="12-23-2013" component="TSPxe" context="" type="0" thread="1932"
    file="tspxe.cpp:185">
    <![LOG[Failed to download pxe variable file. Code(0x00000001)]LOG]!><time="16:15:29.194+000" date="12-23-2013" component="TSPxe" context="" type="3" thread="1932" file="tspxe.cpp:185">
    <![LOG[PxeGetPxeData failed with 0x80004005]LOG]!><time="16:15:29.194+000" date="12-23-2013" component="TSPxe" context="" type="3" thread="1932" file="tsmbootstraputil.cpp:1419">
    <![LOG[HRESULT_FROM_WIN32(dwError), HRESULT=80004005 (e:\nts_sms_fre\sms\client\tasksequence\tsmbootstrap\tsmbootstraputil.cpp,1420)]LOG]!><time="16:15:29.194+000" date="12-23-2013" component="TSPxe" context=""
    type="0" thread="1932" file="tsmbootstraputil.cpp:1420">
    <![LOG[TSMBootstrapUtil::PxeGetPxeData(&bPxeBooted, sVariablesFile, sPxePasswd), HRESULT=80004005 (e:\nts_sms_fre\sms\client\tasksequence\tsmbootstrap\tsmediawizardcontrol.cpp,2236)]LOG]!><time="16:15:29.194+000" date="12-23-2013"
    component="TSPxe" context="" type="0" thread="1932" file="tsmediawizardcontrol.cpp:2236">
    <![LOG[oTSMediaWizardControl.Run( sMediaRoot, true, true ), HRESULT=80004005 (e:\nts_sms_fre\sms\client\tasksequence\tsmbootstrap\tsmbootstrap.cpp,937)]LOG]!><time="16:15:29.194+000" date="12-23-2013" component="TSPxe"
    context="" type="0" thread="1932" file="tsmbootstrap.cpp:937">
    <![LOG[Execute( eExecutionEnv, sConfigPath, sTSXMLFile, uBootCount, &uExitCode ), HRESULT=80004005 (e:\nts_sms_fre\sms\client\tasksequence\tsmbootstrap\tsmbootstrap.cpp,1106)]LOG]!><time="16:15:29.194+000" date="12-23-2013"
    component="TSPxe" context="" type="0" thread="1932" file="tsmbootstrap.cpp:1106">
    <![LOG[Exiting with return code 0x80004005]LOG]!><time="16:15:29.194+000" date="12-23-2013" component="TSPxe" context="" type="1" thread="1932" file="tsmbootstrap.cpp:1118">
    <![LOG[Execution complete.]LOG]!><time="16:15:29.194+000" date="12-23-2013" component="TSBootShell" context="" type="1" thread="880" file="bootshell.cpp:624">
    <![LOG[Finalizing logging from process 832]LOG]!><time="16:15:29.194+000" date="12-23-2013" component="TSBootShell" context="" type="1" thread="880" file="tslogging.cpp:1736">
    <![LOG[Finalizing logs to root of first available drive]LOG]!><time="16:15:29.194+000" date="12-23-2013" component="TSBootShell" context="" type="1" thread="880" file="tslogging.cpp:1578">
    <![LOG[LOGGING: Setting log directory to "D:\SMSTSLog".]LOG]!><time="16:15:29.491+000" date="12-23-2013" component="TSBootShell" context="" type="1" thread="880" file="tslogging.cpp:1803">
    This has been an extremely frustrating issue and any assistance would be greatly appreciated!

    Thanks for your quick response Jason!  I didn't expect someone to reply so quickly or I would have checked back sooner. 
    I had found the two 'older' posts already, but had not seen the 'newer' one.  Unfortunately that did not give me any new ideas.  But your comment on checking for TFTP availability did.  Here are things I have tried since my original
    post...
    I re-ran most of my tests in case I missed something.  I only found one change.  Even though I double-checked, I must have made a typo when I manually ran the smstftp.exe command, because when I ran it again I received a timeout message instead
    of file not found.
    I had a minor 'thinking outside of the box moment' and decided to PXE boot the new 2008 R2 server itself.  This was successful and I interpreted the success as meaning that the hardware is ok.  Thinking there may be a compatibility issue with
    the hardware and the OS, I tried a few different NIC drivers, settings, registry keys, and even a completely different NIC.  No luck on any of these.
    I decided to build another Server on a VM tovalidate my build process and configuration.  And of course clients in multiple locations were able to PXE boot off this VM.  Too bad I can't use this in production.
    After reading your response Jason, I began to focus on network.  I moved the server to a few different locations so it was utilizing different switches.  No luck.  I noticed in the event viewer for WDS that the server was logging the
    beginning of the boot.var file via TFTP.  This of course was not very surprising.  What was surprising is that the very next entry (informational) noted that the client 'COMPLETED' the download of the boot.var file via TFTP.  I know that completed
    does not mean successful, but it usually implies or is interpreted as successful.  It should have logged a warning or error, or nothing at all because although the process completed, it was not successful.  I re-verified that the file was not downloaded
    to the client and the client log file still shows the same error noted in the logfile from my original post.
    Finally, I installed sniffing software on the server and ran some captures while attempting to PXE boot.  Even though I am not much of a network guy, I quickly discovered two things.  First, I found the section where the client attempts to download
    the boot.var file.  Unfortunately I don't think the local security team will allow me to post the capture, so I'll do my best to describe what I found.  It starts with a single entry where the client calls for the file via TFTP protocol.  This
    is followed by a series of alternating entries (all TFTP) where it looks like the server attempts to send a portion of the file, and the client sends an acknowledgement.  The sending entries all have checksum errors.  The checksum received on
    all packets is 0x0000 and of course should be something else.  There is also a shorter section below this with alternating entries where the server attempts to send ICMP packets and the client responds with TFTP acknowledgements. 
    The ICMP entries are all marked as Destination unreachable (Port Unreachable).
    The second thing I noticed from the network capture is the a few 'Spanning Tree Protocol' entries.  I my search for a solution, I remember reading several posts saying that Spanning Tree can cause this issue.  When I asked, I was assured that
    Spanning Tree was disabled in this environment.  It made sense too, because the 2003 PXE server was functioning properly, and Spanning Tree should affect both 2003 and 2008 servers, right?
    Either way I will bring my findings to the network team and see what they have to say.
    Any additional thoughts or ideas???

  • Machines cannot PXE boot using SCCM 2012 DP

    There are a lot of posts about PXE boot, but I can't find the common thread to tie them all together.  My test machines cannot PXE boot.
    My lab environment is very simple:
    10.10.0.0/24 subnet
    10.10.0.10 = W2k8 R2 DC, DHCP, DNS
    10.10.0.11 = SCCM2012 (on W2k8R2 with SQL Server 2008 SP3 and CU4)
    All machines are Hyper-V virtual machines connecting through the same virtual network.
    Setup the PXE service from DP properties.  I let SCCM install WDS.  WDS in Server Manager does not have a server node, but the WDS service is running.  DP PXE tab is configured as follows:
    "Enable PXE support for clients" is checked
    "Allow this distribution point to resond to incoming PXE requests" is checked
    "Enable unknown computer support" is checked
    "Require a password when computers use PXE" is not checked
    "User device affinity" is set to "Allow user device affinity with automatic approval"
    PXE is configured to respond on all network interfaces
    The PXE server response delay is 0 seconds
    The DHCP server has options configured as follows:
    Option 66: 10.10.0.11
    Option 67: smsboot\x86\wdsnbp.com
    Both DP and MP on SCCM server are configured for HTTP.
    Both x86 and x64 boot images have been distributed to DP.  The media was updated after PXE was enabled on the DP.
    Both x86 and x64 boot images have "Deploy this image from the PXE service point" enabled on the Data Source tab of their properties.
    I have tried both unknown computer task sequence and a computer import task sequence (old computer association).  They all end in abortpxe.com
    Complete PXE response is as follows:
    =================================================================
    PXE Network Boot 03.23.2009
    (C) Copyright 2009 Microsoft Corporation, All Rights Reserved
    CLIENT MAC ADDR: 00 DD CC BB AA 00  GUID: 532D27E3-A184-4D27-A822-30A8B6F4A39D
    CLIENT IP: 10.10.0.106    MASK: 255.255.255.0    DHCP IP: 10.10.0.10
    GATEWAY IP: 10.10.0.5
    Download WDSNBP...
    Architecture: x64
    WDSNBP started using DHCP Referral.
    Contacting Server: 10.10.0.11 (Gateway: 0.0.0.0)
    The detalis below show the information relating to the PXE boot request for
    this computer.  Please provide these details to your Windows Deployment Services
    Administrator so that this request can be approved.
    Pending Request ID: 6
    Contacting Server: 10.10.0.11
    TFTP Download: smsboot\x64\abortpxe.com
    PXE Boot aborted.  Booting to next device
    =========================================================== 
    From the smspxe.log:
    ]LOG]!><time="16:31:39.445+240" date="05-06-2012" component="SMSPXE" context="" type="1" thread="3600" file="libsmsmessaging.cpp:6402">
    <![LOG[Client Identity: {C9929C4D-735A-4973-8659-4D3D5D5E4F92}]LOG]!><time="16:31:39.445+240" date="05-06-2012" component="SMSPXE" context="" type="1" thread="3600" file="libsmsmessaging.cpp:6428">
    <![LOG[Set enterpirse certificate in transport]LOG]!><time="16:31:39.480+240" date="05-06-2012" component="SMSPXE" context="" type="1" thread="3600" file="libsmsmessaging.cpp:9207">
    <![LOG[Set media certificate in transport]LOG]!><time="16:31:39.505+240" date="05-06-2012" component="SMSPXE" context="" type="1" thread="3600" file="libsmsmessaging.cpp:9220">
    <![LOG[Set authenticator in transport]LOG]!><time="16:31:39.505+240" date="05-06-2012" component="SMSPXE" context="" type="1" thread="3600" file="libsmsmessaging.cpp:7592">
    <![LOG[Set authenticator in transport]LOG]!><time="16:31:39.533+240" date="05-06-2012" component="SMSPXE" context="" type="1" thread="3600" file="libsmsmessaging.cpp:7592">
    <![LOG[PXE::CBootImageManager::FindMatchingArchitectureBootImage]LOG]!><time="16:31:39.553+240" date="05-06-2012" component="SMSPXE" context="" type="1" thread="3600" file="bootimagemgr.cpp:1736">
    <![LOG[PXE::CBootImageManager::FindMatchingArchitectureBootImage]LOG]!><time="16:32:00.963+240" date="05-06-2012" component="SMSPXE" context="" type="1" thread="3600" file="bootimagemgr.cpp:1736">
    <![LOG[Set enterpirse certificate in transport]LOG]!><time="16:32:01.008+240" date="05-06-2012" component="SMSPXE" context="" type="1" thread="3600" file="libsmsmessaging.cpp:9207">
    <![LOG[Set media certificate in transport]LOG]!><time="16:32:01.027+240" date="05-06-2012" component="SMSPXE" context="" type="1" thread="3600" file="libsmsmessaging.cpp:9220">
    <![LOG[Set authenticator in transport]LOG]!><time="16:32:01.027+240" date="05-06-2012" component="SMSPXE" context="" type="1" thread="3600" file="libsmsmessaging.cpp:7592">
    <![LOG[Set authenticator in transport]LOG]!><time="16:32:01.084+240" date="05-06-2012" component="SMSPXE" context="" type="1" thread="3600" file="libsmsmessaging.cpp:7592">
    <![LOG[Client boot action reply: <ClientIDReply><Identification Unknown="0" ItemKey="16777218" ServerName="" ServerRemoteName=""><Machine><ClientID/><NetbiosName/></Machine></Identification><PXEBootAction LastPXEAdvertisementID=""
    LastPXEAdvertisementTime="" OfferID="" OfferIDTime="" PkgID="" PackageVersion="" PackagePath="" BootImageID="" Mandatory=""/></ClientIDReply>
    ]LOG]!><time="16:32:01.108+240" date="05-06-2012" component="SMSPXE" context="" type="1" thread="3600" file="libsmsmessaging.cpp:6402">
    <![LOG[Client Identity: {C9929C4D-735A-4973-8659-4D3D5D5E4F92}]LOG]!><time="16:32:01.108+240" date="05-06-2012" component="SMSPXE" context="" type="1" thread="3600" file="libsmsmessaging.cpp:6428">
    <![LOG[Set enterpirse certificate in transport]LOG]!><time="16:32:01.151+240" date="05-06-2012" component="SMSPXE" context="" type="1" thread="3600" file="libsmsmessaging.cpp:9207">
    <![LOG[Set media certificate in transport]LOG]!><time="16:32:01.174+240" date="05-06-2012" component="SMSPXE" context="" type="1" thread="3600" file="libsmsmessaging.cpp:9220">
    <![LOG[Set authenticator in transport]LOG]!><time="16:32:01.174+240" date="05-06-2012" component="SMSPXE" context="" type="1" thread="3600" file="libsmsmessaging.cpp:7592">
    <![LOG[Set authenticator in transport]LOG]!><time="16:32:01.209+240" date="05-06-2012" component="SMSPXE" context="" type="1" thread="3600" file="libsmsmessaging.cpp:7592">
    <![LOG[PXE::CBootImageManager::FindMatchingArchitectureBootImage]LOG]!><time="16:32:05.230+240" date="05-06-2012" component="SMSPXE" context="" type="1" thread="3600" file="bootimagemgr.cpp:1736">
    <![LOG[Set enterpirse certificate in transport]LOG]!><time="16:32:05.290+240" date="05-06-2012" component="SMSPXE" context="" type="1" thread="3600" file="libsmsmessaging.cpp:9207">
    <![LOG[Set media certificate in transport]LOG]!><time="16:32:05.325+240" date="05-06-2012" component="SMSPXE" context="" type="1" thread="3600" file="libsmsmessaging.cpp:9220">
    <![LOG[Set authenticator in transport]LOG]!><time="16:32:05.325+240" date="05-06-2012" component="SMSPXE" context="" type="1" thread="3600" file="libsmsmessaging.cpp:7592">
    <![LOG[Set authenticator in transport]LOG]!><time="16:32:05.366+240" date="05-06-2012" component="SMSPXE" context="" type="1" thread="3600" file="libsmsmessaging.cpp:7592">
    <![LOG[Client boot action reply: <ClientIDReply><Identification Unknown="0" ItemKey="16777218" ServerName="" ServerRemoteName=""><Machine><ClientID/><NetbiosName/></Machine></Identification><PXEBootAction LastPXEAdvertisementID=""
    LastPXEAdvertisementTime="" OfferID="" OfferIDTime="" PkgID="" PackageVersion="" PackagePath="" BootImageID="" Mandatory=""/></ClientIDReply>
    =============================================================================================
    I've been hammering this for about 10 hours now (or to be honest, it's been hammering me) and it must be something very simple I'm missing.  I have a feeling that I'm doing something I used to do in 2007 and whatever that is, it does not work in
    2012.
    If I connect using boot media, Task Sequences execute perfectly.
    TIA,
    Tom

    Option 66: 10.10.0.11
    Option 67: smsboot\x86\wdsnbp.com
    Pending Request ID: 6
    Contacting Server: 10.10.0.11
    TFTP Download: smsboot\x64\abortpxe.com
    PXE Boot aborted.  Booting to next device
    <![LOG[Client boot action reply: <ClientIDReply><Identification Unknown="0" ItemKey="16777218" ServerName="" ServerRemoteName=""><Machine><ClientID/><NetbiosName/></Machine></Identification><PXEBootAction
    LastPXEAdvertisementID="" LastPXEAdvertisementTime="" OfferID="" OfferIDTime="" PkgID="" PackageVersion="" PackagePath="" BootImageID="" Mandatory=""/></ClientIDReply>
    Those options are fine when using DHCP options. They must be configured right because ConfigMgr does send a reply to the client ("abortpxe"). It basically tells you that ConfigMgr knows the MAC address and/or SMBIOSGUID of the client, but cannot find
    a deployment for it.
    Just find ResourceID 16777218 in the console (you might have to add the ResourceID column) and double check if there's an deployment available (properties of the client with resourceID 16777218).
    Torsten Meringer | http://www.mssccmfaq.de
    Your answer really helped me. I was searching for 2 days trying to find a computer in Config Manager. Your suggestion to "Just
    find ResourceID 16777218 in the console (you might have to add the ResourceID column) and double check if there" was the trick to finding the computer in Config Manager. Thanks for all of your help
    Gregory Campbell System Administrator

  • SCCM 2012 pxe boot issue

    My test machines cannot PXE boot.
    My lab environment is very simple:
    10.10.0.0/24 subnet
    10.10.0.5 = Server2012, DHCP, DNS, SQL Server 2008 R2 Sp2
    10.10.0.7 = Server2012, SCCM2012
    All machines are Oracle VM Box virtual machines connecting through the same virtual network.
    Setup the PXE service from DP properties.  I let SCCM install WDS.  WDS in Server
    Manager does not have a server node, but the WDS service is running.  DP PXE tab is configured as follows:
    "Enable PXE support for clients" is checked
    "Allow this distribution point to respond to incoming PXE requests" is checked
    "Enable unknown computer support" is checked
    "Require a password when computers use PXE" is not checked
    "User device affinity" is set to "Allow user device affinity with automatic approval"
    PXE is configured to respond on all network interfaces
    The PXE server response delay is 0 seconds
    The DHCP server has options configured as follows:
    Option 66: 10.10.0.7
    Option 67: smsboot\x86\wdsnbp.com
    Both DP and MP on SCCM server are configured for HTTP.
    Both x86 and x64 boot images have been distributed to DP.  The media was updated after
    PXE was enabled on the DP.
    Both x86 and x64 boot images have "Deploy this image from the PXE service point" enabled on the Data Source tab of their properties
    SMSPXE.Log
    <![LOG[Client boot action reply: <ClientIDReply><Identification Unknown="0" ItemKey="16777219" ServerName=""><Machine><ClientID/><NetbiosName/></Machine></Identification><PXEBootAction
    LastPXEAdvertisementID="" LastPXEAdvertisementTime="" OfferID="" OfferIDTime="" PkgID="" PackageVersion="" PackagePath="" BootImageID="" Mandatory=""/></ClientIDReply>
    ]LOG]!><time="15:05:09.346-330" date="07-07-2014" component="SMSPXE" context="" type="1" thread="13592" file="libsmsmessaging.cpp:6544">
    <![LOG[08:00:27:61:59:79, BF2ACCDD-1455-E149-963C-9A845B9C111E: no advertisements found]LOG]!><time="15:05:09.346-330" date="07-07-2014" component="SMSPXE" context="" type="1" thread="13592"
    file="database.cpp:483">
    <![LOG[08:00:27:61:59:79, BF2ACCDD-1455-E149-963C-9A845B9C111E: No boot action. Aborted.]LOG]!><time="15:05:09.441-330" date="07-07-2014" component="SMSPXE" context="" type="1" thread="13592"
    file="database.cpp:483">
    <![LOG[08:00:27:61:59:79, BF2ACCDD-1455-E149-963C-9A845B9C111E: Not serviced.]LOG]!><time="15:05:09.441-330" date="07-07-2014" component="SMSPXE" context="" type="1" thread="13592" file="database.cpp:483">
    <![LOG[Client boot action reply: <ClientIDReply><Identification Unknown="0" ItemKey="16777219" ServerName=""><Machine><ClientID/><NetbiosName/></Machine></Identification><PXEBootAction
    LastPXEAdvertisementID="" LastPXEAdvertisementTime="" OfferID="" OfferIDTime="" PkgID="" PackageVersion="" PackagePath="" BootImageID="" Mandatory=""/></ClientIDReply>
    ]LOG]!><time="15:05:09.705-330" date="07-07-2014" component="SMSPXE" context="" type="1" thread="13592" file="libsmsmessaging.cpp:6544">
    <![LOG[08:00:27:61:59:79, BF2ACCDD-1455-E149-963C-9A845B9C111E: no advertisements found]LOG]!><time="15:05:09.705-330" date="07-07-2014" component="SMSPXE" context="" type="1" thread="13592"
    file="database.cpp:483">

    Resource ID is already present in the Unknown Computer (Windows 7) Properties please look into it and
    OSD Task Sequences is there :(.

  • Windows server 2012 R2 PXE boot is unworkable slow, I have this exact same set-up working in 2008 R2 What can I do?

    Hi there
    I'm trying to deploy a windows 7 image through Windows deployment services via PXE boot from a 2012 R2 server.
    Issue:    PXE boot is extremely slow, it takes up to more than 60 minutes for the device to download download the PXE boot
    Things I already tried to get this up and running:
    I've tried to change the TFTP block size via command prompt and via regedit
    I've changed the settings on the tab of the WDS role (go to WDS role -> properties on server -> Tab "tftp")
    Both actions resulted in PXE boot being even slower than it already was.
    To make sure this is not because of our environment I’ve set up the same configuration on a windows server 2008 R2, here PXE boot image is downloaded to the machine within 3 minutes.
    Both servers are set up through Hyper-V this is the configuration:
    2008 R2:
    Memory: 4096 MB
    1 Virtual processor
    IDE controller 2 hard drives
    Network adapter
    2012 R2:
    Memory: 4096 MB
    32 virtual processors
    SCSI controller 2 hard drives
    Network adapter
    I can’t imagine that PXE boot is not working because of the differences of the Hard drives controllers or because of the amount of the virtual processors.
    Windows server 2012 R2 seems to handle PXE boot TFTP differently in comparison to 2008 R2.
    Do you guys know what I can do/try to get this working?

    Hi Jacques Rodrigues,
    You can run Windows Deployment Services on Hyper-V virtual machines,
    that the performance will often be degraded, particularly during the Trivial File Transfer Protocol (TFTP) download phase. This phase is very resource-intensive and may
    fail if insufficient resources are available on your server running Hyper-V.
    If you are using multicast, Check if IGMP Snooping is enabled i.e. Routers that support multicasting. In particular, Internet Group Membership Protocol (IGMP) snooping should
    be enabled on all devices. This will cause your network hardware to forward multicast packets only to those devices that are requesting data. If IGMP snooping is turned off, multicast packets are treated as broadcast packets, and will be sent to every device
    in the subnet.
    The related KB:
    Windows Deployment Services Overview
    http://technet.microsoft.com/en-us/library/hh831764.aspx
    I’m glad to be of help to you!
    We
    are trying to better understand customer views on social support experience, so your participation in this
    interview project would be greatly appreciated if you have time.
    Thanks for helping make community forums a great place.

  • PXE boot and video mode

    Hello all,
    I posted about this problem a while ago but now I have more information.
    6.5 SP2 IR1.
    The problem: Booting from CD results in a video mode with far more lines and
    column than booting PXE. PXE is always 80x25, on many different hardware
    types. I want it to be like the CD.
    Theoretically, the video mode is controlled by the vga= parameter on the
    kernel's command line. For PXE, the kernel command line comes from <imaging
    server>\sys\tftp\cmds, various files therein. Here are the contents of a
    typical file:
    KERNEL boot/linux
    APPEND initrd=boot/initrd vga=0x314 install=tftp://$TFTPIP/boot
    rootimage=/root PROXYADDR=$PROXYADDR TFTPIP=$TFTPIP splash=silent
    PXEBOOT=YES mode=5
    Notice the vga= parameter.
    I can modify this vga parameter any way I like, without effect. I have
    tried:
    - removing the parameter entirely
    - setting it to ask
    - setting it to vga_ask
    - setting it to single-digit numbers e.g. 1, 2
    - setting it to other 0x3nnn options
    - setting it to extended
    It should be possible for anybody to replicate this simply by changing the
    vga parameter in one of your CMD files and booting that particular PXE
    option. I suggest using "ask" as it is the one that would give the most
    visibly obvious evidence of working or not working.
    The boot loader for PXE appears to be linld.com. So, I took my PXE
    materials and Novell's linld (to ensure same version) and ran them from DOS.
    When I run them from DOS, the vga= parameter DOES have an effect; it behaves
    exactly as it should.
    So, the situation appears to be that linld launched via PXE ignores the vga
    parameter while linld launched manually from DOS does not, on the same
    hardware.
    Working with linld under DOS yielded some interesting information. The text
    files specifying the kernel command line parameters for PXE are not actually
    in anything remotely like the format linld requires. Having KERNEL and
    APPEND keywords is more characteristic of other boot loaders. If you run
    linld without parameters under DOS, it gives you very terse command line
    information, which is as follows:
    LINLD v0.97
    Syntax:
    LINLD [image=<file>] [initrd=<file>] [vga=vgamode] [cl=<kernel cmdline>]
    vgamode: ask,extended,normal or dec/oct/hex number
    Use quotes: "cl=..." if you need spaces in cmdline
    Use cl=@filename to take cmdline from file
    So compared to the CMD file provided for PXE, what linld would really want
    is this:
    linld image=boot/linux initrd=boot/initrd vga=0x314 [email protected]
    where params.txt would contain:
    install=tftp://$TFTPIP/boot
    rootimage=/root
    PROXYADDR=$PROXYADDR
    TFTPIP=$TFTPIP
    splash=silent
    PXEBOOT=YES
    mode=5
    (It's worth noting that things are actually even slightly more complicated,
    because the variables used in the CMD file (e.g. $PROXYADDR) don't actually
    work; I have not found any way to use variables on the command line.)
    All this tells me that before Novell launches linld, it is internally
    processing the contents of these CMD files and spitting out a command line
    that linld can really work with. My experience indicates that the vga
    parameter is being incorrectly handled in this process.
    I cannot figure out where the DOS environment that must exist during the PXE
    boot process is coming from. (There must be a DOS environment, because
    linld is a DOS Linux launcher.) It was easy to tell with the old preworx
    materials, because you could see the .bin files which were nothing but
    images of DOS boot floppies; it was even possible to open them in
    third-party PXE utilities. I see no comparable files in the current boot
    materials. The only other interesting file is loadlin.dnx, but I suspect it
    is not involved because the old preworx process had DNX files as well and
    they served a different purpose. Consequently I can't look at what is
    happening when linld is launched, so I can't get any further in trying to
    figure out the problem.
    I would be very interested to know whether anybody out there can get their
    PXE materials to respond sensibly to vga=ask.
    If you can, I'd be interested to know the dates and times of all the backend
    NLMs, in case my problem is due to incorrect updating/version mismatch.
    If anybody can shed light on the innards of what happens when linld is
    launched during PXE boot, I would love to know.
    Thanks,
    Lisa.

    Lisa,
    It appears that in the past few days you have not received a response to your
    posting. That concerns us, and has triggered this automated reply.
    Has your problem been resolved? If not, you might try one of the following options:
    - Do a search of our knowledgebase at http://support.novell.com/search/kb_index.jsp
    - Check all of the other support tools and options available at
    http://support.novell.com.
    - You could also try posting your message again. Make sure it is posted in the
    correct newsgroup. (http://support.novell.com/forums)
    Be sure to read the forum FAQ about what to expect in the way of responses:
    http://support.novell.com/forums/faq_general.html
    If this is a reply to a duplicate posting, please ignore and accept our apologies
    and rest assured we will issue a stern reprimand to our posting bot.
    Good luck!
    Your Novell Product Support Forums Team
    http://support.novell.com/forums/

Maybe you are looking for