CMD Not Recognizing Most Commands RRS feed

  • Question

  • I am working with a copy of Win 7 Ent that was sysprepped by another agency. I deploy the image with SCCM 2007R3. This is an intranet not connected to the www so I have to troubleshoot by recalling errors from written notes or memory.

    After image deployment, the computer is initially a workgroup member. If I log on locally with the built in Administrator, I can't execute a simple .exe, .cmd, .bat (i.e., setup.exe) from the Administrator desktop (the setup.exe is also on the desktop). The response from cmd is "'setup.exe' is not recognized as an internal or external command, operable program or batch file". If I move the .exe to the %systemroot% and run cmd from there, it executes fine.

    I have already looked for environmental path variables using the PATH command, and all the anticipated one's are there, including c:\windows and c:\windows\system32. I don't know which others should be there contributing to this?

    This only happens on the local administrator/administrators desktop. If I join it to the domain, this problem doesn't happen with my admin desktop, nor is there any problem with SCCM distributing software packages.

    I'm seeking advice on this because I'm also having a problem getting SCCM to deploy the above .exe during an OSD task sequence, and I'm not sure if they're related but if I can fix what's going on here I wanted to test the .exe deployment with SCCM and see if it's fixed.

    Thanks if you have any thoughts or advice on this.

    Thursday, June 20, 2013 9:35 PM

All replies

  • Have a look at HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\Path.

    - What type of value is "Path"?
    - What exactly is its data? (use copy & paste to report it)

    Thursday, June 20, 2013 10:27 PM
  • Oberwald,

    Thanks for the tip. I'm not back into the server room until Monday but I'll look at that and let you know. Thanks.

    Thursday, June 20, 2013 11:23 PM
  • Hi,

    Any update?

    Tracy Cai
    TechNet Community Support

    Monday, June 24, 2013 9:30 AM
  • Tracy I'm going to try to get that info tomorrow or Wednesday.

    Unfortunately I'm in an extremely locked down network. I will have to hand transcribe the "path" value list to the www, because the network that workstation is on is on an intranet with no connectivity to the www. Even the network that connects to the www there is so locked down I can read Technet forums but the script that needs to run to let me log in and post is blocked. A very heavily secured and pain in the rearend situation for sure.

    I do remember "path" being REG_EXPAND_SZ, so all I'll have to do is list out the values, bring them home and post them up for you to look at. Thanks for your help and patience.

    Monday, June 24, 2013 11:06 PM
  • Hello,

    Value of \Environment\Path is


    C:\Program Files (x86)\NVIDIA Corporation PhysX\Common;




    C:\Program Files (x86)\Microsoft Application Virtualization Client;

    %SystemRoot%\system32\Windows System Resource Manager\bin;



    c:\Program Files (x86)\Microsoft SQL Server\90\Tools\binn\;

    C:\Program Files (x86)\Common Files\Roxio Shared\DLLShared\;

    C:\Program Files (x86)\Common Files\Roxio Shared\10.0\DLLShared\

    Tuesday, June 25, 2013 8:52 PM
  • I will have to hand transcribe the "path" value list to the www,
    -> Why not use a flash disk? Far less tedious and much more accurate!

    Value of \Environment\Path is REG_EXPAND_SZ
    -> This is unusual but it is required when the path contains %variables%. Anyway, it should work.

    Did you check the value of %PathExt%? It should be

    Tuesday, June 25, 2013 9:41 PM
  • Obenwald, I will follow up on your suggestion tomorrow.

    We are permitted only read-only media on the system.

    Thanks and will let you know.

    Tuesday, June 25, 2013 10:01 PM
  • Obenwald, yes, those values are present.

    I appreciate your help but not sure how much farther I should investigate this. I was suspicious it was causing an issue with software deployment during SCCM OSD, but I've since found out that was caused by another issue...static addressing the nic (we can't use DHCP) is lost after the first restart, then when the task sequence tries to go back to the SCCM server for the software package, it gets an invalid DHCP address and the operation (OSD follow-on software deployment) fails.

    Not a biggie at this point. Plus, this issue with CMD doesn't seem to affect anything once the computer is joined to the domain and I log in with an admin account...everything works.

    Anyway, I appreciate your efforts to help me solve this one.

    Thursday, June 27, 2013 10:33 PM