none
[SOLVED] Root Cause/Actual Fix for No Physical adapters present, cannot deploy over wireless RRS feed

  • Question

  • I tend to get the 'No physical adapters present, cannot deploy over wireless' error periodically.  While I'm certain I've seen it when deploying, I happened to be sysprepping & capturing [a VMWare virtual machine] when I received it.

    All is well however: 

    • sysprepped [reference] image without error
    • captured without error
    • [reference] system reboots & boots fine
    • successfully imported captured image
    • successfully deployed captured image

    So several questions...

    • Anyone know what the root cause of that is?
    • Is there an actual way to fix that?  (Perhaps adding some [enhanced/additional] logic to whatever script is called that generates the error?)
    • Why do I get it 5 times?



    Note:

    1. I'm fully aware of leveraging SkipSummary=YES/SkipFinalSummary=YES - just looking for a real reason why that's even an 'issue'
    2. This was covered elsewhere (http://social.technet.microsoft.com/Forums/en-US/mdt/thread/894ee6d2-a7b9-427f-a9b7-9a43dcc04d27/) but I didn't want to threadjack.



    Many thanks!


    • Edited by JuliusPIV Thursday, April 2, 2015 2:09 PM
    Tuesday, May 21, 2013 5:10 PM

Answers

  • I just did some investigation on another thread related to "No Physical Adapters Present".

    You should never see networking errors *after* sysprep. One of the steps of Sysprep is to *REMOVE* all network adapters from the local binding order. Why would you try to be using the network if there are no more network adapters? The MDT team has tested this, and there should be no MDT code that uses the network after Sysprep.

    What I found on the other thread is that the MDT user had set SLSHareDynamicLogging, and MDT was attempting to write to the network, and of course not finding any local network adapters.

    I *NEVER* recommend using SLShareDynamicLogging for anything. For reasons just like this one.


    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Saturday, September 13, 2014 4:56 AM
    Moderator

All replies

  • Periodically, MDT will check for network connectivity.  See ZTIUtility.vbs --> ValidateNetworkConnectivity()

    It's possible that your wired network has the word "wireless" in the title, confusing the heuristic.

    On a VM, check the following in powershell:

    gwmi win32_NetworkAdapterconfiguration | ?{ $_.ipenabled } | %{ $_.caption }


    Keith Garner - keithga.wordpress.com

    Monday, July 22, 2013 8:54 PM
    Moderator
  • As far as I've seen this happens in WinPE after Sysprep so powershell won't help very much here I guess.

    The workaround for me was to slightly modify ZTIUtility.vbs. I searched the script for the line that contains the error message and there I replaced "logtypeerror" against "logtypeinfo".

    Since I only use MDT to create my custom images on vmware machines for our 3rd party deployment system, I'm fine with this approach.

    Wednesday, August 14, 2013 12:08 PM
  • Keith: Thanks for the reply.  I'm not sure why I didn't see this sooner.

    I think I only ever see this at the end of a sysprep & capture TS (cscript litetouch.wsf) while in WinPE on VMware & VirtualBox VMs.  Regular deployments to these VMs work fine.

    While in Windows, none of the adapters have wireless in the name.  When I'm in WinPE, I can't run that exact command, but I can do something similar:

    wmic path win32_networkadapterconfiguration where ipenabled=true get caption

    And it returns with "Intel(R) PRO/1000 MT Desktop Adapter"; no wireless there either.

    Wednesday, September 10, 2014 4:28 PM
  • Thanks Hohlmesser for the reply!

    I agree that I'm only seeing this in WinPE after Sysprep and since there's no PowerShell Keith's command won't work but there's a workaround for that:

    wmic path win32_networkadapterconfiguration where ipenabled=true get caption,ipconnectionmetric
    For the 'Intel(R) PRO/1000 MT Desktop Adapter' in my VirtualBox VM, the IPConnectionMetric is 10, not "". The plot thickens.

    I took a look at ZTIUtility.vbs and found the section of code and I'm noticing that the specific section of code that returns the error is checking the value of 'sIPConnectionMetric'.  I added some additional logging in that section so I can see exactly what's being returned by the query.

    Here's what I'm running now just to generate more information in the logs.  From there, as time permits, I'll see if it makes sense to create exceptions to the code.

    'Check for wireless connectivity
    
    Set colAdapters = objWMI.ExecQuery("select * from win32_NetworkAdapterconfiguration where IPEnabled = True")
    For Each oAdapter in colAdapters
    	If Instr(UCase(oAdapter.Caption),"WIRELESS") = 0 Then
    oLogging.CreateEntry "oAdapter.Caption (" & oAdapter.Caption & ") Contains ""WIRELESS""", LogTypeInfo
    
    If oAdapter.IPConnectionMetric < sIPConnectionMetric Or sIPConnectionMetric = "" Then
    	oLogging.CreateEntry "oAdapter.IPConnectionMetric (" & oAdapter.IPConnectionMetric & ") < sIPConnectionMetric (" & sIPConnectionMetric & ") Or sIPConnectionMetric = """" (" & sIPConnectionMetric & ")", LogTypeInfo
    	sIPConnectionMetric = oAdapter.IPConnectionMetric
    	oLogging.CreateEntry "sIPConnectionMetric is '" & sIPConnectionMetric & "' / oAdapter.IPConnectionMetric is '" & oAdapter.IPConnectionMetric & "'", LogTypeInfo
    Else
    	oLogging.CreateEntry "NOT oAdapter.IPConnectionMetric (" & oAdapter.IPConnectionMetric & ") < sIPConnectionMetric (" & sIPConnectionMetric & ") Or sIPConnectionMetric = """" (" & sIPConnectionMetric & ")", LogTypeInfo
    End If
    	Else
    oLogging.CreateEntry "oAdapter.Caption (" & oAdapter.Caption & ") DOES NOT ""WIRELESS""", LogTypeInfo
    	End IF
    	
    	If Instr(UCase(oAdapter.Caption),"WIRELESS") Then
    oLogging.CreateEntry "oAdapter.Caption (" & oAdapter.Caption & ") Contains ""WIRELESS""", LogTypeInfo
    sWirelessConnectionMetric = oAdapter.IPConnectionMetric
    oLogging.CreateEntry "sWirelessConnectionMetric is '" & sWirelessConnectionMetric & "' / oAdapter.IPConnectionMetric is '" & oAdapter.IPConnectionMetric & "'", LogTypeInfo
    	Else
    oLogging.CreateEntry "oAdapter.Caption (" & oAdapter.Caption & ") DOES NOT Contain ""WIRELESS""", LogTypeInfo
    	End If
    
    Next
    
    If sIPConnectionMetric = "" Then
    	oLogging.CreateEntry "sIPConnectionMetric (" & sIPConnectionMetric & ") = """"", LogTypeInfo
    	'oLogging.CreateEntry "No physical adapters present, cannot deploy over wireless", LogTypeError
    	oLogging.CreateEntry "No physical adapters present, cannot deploy over wireless:" & vbCrLf & "sIPConnectionMetric is '" & sIPConnectionMetric & "'", LogTypeError
    	ValidatenetworkConnectivity = Failure
    	Exit Function
    Else
    	oLogging.CreateEntry "sIPConnectionMetric (" & sIPConnectionMetric & ") DOES NOT = """"", LogTypeInfo
    End If

    Your suggestion is a good one, but I don't want to eliminate that error entirely as it may highlight a legitimate issue in the future.


    • Edited by JuliusPIV Wednesday, September 10, 2014 5:24 PM
    Wednesday, September 10, 2014 4:48 PM
  • I get this error on Windows Server 2008 R2, specifically when I use captured WIMs for the deployment.

    Did anyone tried this VMware kb article ?

    http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1020078


    Regards Sivakarthi

    Thursday, September 11, 2014 7:56 PM
  • Interesting find.  I'm not using VMware but its something to consider.

    What's really odd is that I don't always get it.

    The other side is that my organization is still using MDT 2010.  The RFC for the upgrade to 2013 has been submitted but its gonna take a while.  I'm making an assumption here that this 'problem', so called, is fixed in 2013 but maybe not.  Its not a big deal either - just wanted a better understanding behind the logic in the scripts.

    Friday, September 12, 2014 9:22 PM
  • I just did some investigation on another thread related to "No Physical Adapters Present".

    You should never see networking errors *after* sysprep. One of the steps of Sysprep is to *REMOVE* all network adapters from the local binding order. Why would you try to be using the network if there are no more network adapters? The MDT team has tested this, and there should be no MDT code that uses the network after Sysprep.

    What I found on the other thread is that the MDT user had set SLSHareDynamicLogging, and MDT was attempting to write to the network, and of course not finding any local network adapters.

    I *NEVER* recommend using SLShareDynamicLogging for anything. For reasons just like this one.


    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Saturday, September 13, 2014 4:56 AM
    Moderator
  • I just did some investigation on another thread related to "No Physical Adapters Present".

    You should never see networking errors *after* sysprep. One of the steps of Sysprep is to *REMOVE* all network adapters from the local binding order. Why would you try to be using the network if there are no more network adapters? The MDT team has tested this, and there should be no MDT code that uses the network after Sysprep.

    What I found on the other thread is that the MDT user had set SLSHareDynamicLogging, and MDT was attempting to write to the network, and of course not finding any local network adapters.

    I *NEVER* recommend using SLShareDynamicLogging for anything. For reasons just like this one.


    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Another excellent reply - thanks Keith.

    So you're suggesting that something like the following could be happening:

    1. SLShareDynamicLogging is enabled in TS
    2. Sysprep & capture TS is run
    3. The process is logging normally
    4. At some point, the network adapters are removed
    5. The process is trying to log but can't because sysprep did its job
    6. System reboots
    7. In WinPE drivers are loaded & there's network connectivity
    8. Logging resumes
    9. The warning shown is just a red herring triggered by step 5, a direct result of having SLShareDynamigLogging enabled?

    And I agree: having SLShareDynamicLogging enabled for day to day imaging is no good; should only be used to troubleshoot specific incidents.

    Saturday, September 13, 2014 5:37 AM
  • Thanks Keith. I don't see this error anymore after removing "SLShareDynamicLogging".

    Regards Sivakarthi

    Tuesday, September 16, 2014 2:22 PM
  • All of the discussion on the matter seems to involve a build and capture task sequence. I have a very unique behavior that is occurring only on one site with one model of pc and only when deploying. I cannot seem to get this thing ironed out and am curious what your thoughts are on my specific issue. I have a suspicion as to what the issue is but I can't prove it at the moment unfortunately. Also, I'm more than happy to share logs if needed. 
    Tuesday, November 10, 2015 7:15 PM