I'd imagine if C:\Windows\System32 were missing from the path statement, ipconfig not running would be the least of your worries.
C:\Windows\System32 contains a large number of the executables and dynamic link libraries (DLLs) that allow Windows to function.
An entry in the system Path settings tells the computer to look in that specified location for executables and files that programs are referencing.
While it would seem that a good program would not rely on Path variables but should directly reference the location of any and every file it is dependent on, the Path statement allows multiple similar OSes to coexist on the same drive (Windows XP in the C:\WinXP\ folder, Windows 7 in C:\Win7\, etc, which would result in different and incompatible .\System32\ directories), and allows for more easy and flexible upgrading of framework files (look for the newest version of the .Net libraries in a versioned directory where they are installed rather than a central directory where they may overwrite each other in an undersireable way).
So a program looking to use the functions of Windows XP's built in zip handling would call zipfldr.dll and the OS will return the functions of that executable stored in C:\Windows\System32\zipfldr.dll. If you look through that directory, you should see many files that you'll probably recognize as common scripting commands or functions critical to the OSes operation.
I've never removed the C:\Windows\System32 entry from my path statement and I don't think I ever will (though I suppose testing this in a VM with rollback functionality shouldn't be too hard) and so I cannot say for certain what would happen if it were completely missing.
Suffice it to say, pretty much any batch script would completely not function, and the abilities of your OS would be severely curtailed.
Others have already noted how to add C:\Windows\System32 to the Path statement if it is missing, and so I'll not repeat that here. But I would not be surprised, since this is the only function you've found to be not working, if there were something else wrong here.
Best Answer
The most common reason why a command which runs an executable program works on the command line, but not in a batch script, is that, in the script, prior to the line containing the problem command, the user has created a variable %path%. It might seem a handy name for a variable that holds, well, a path. The problem is that this variable name is used by Windows to hold a semicolon-separated list of folders which are searched when an executable is called. It is a system variable. If you have redefined it, then all executables (e.g. .exe, .bat, .vbs, etc) that Windows uses, will not be found, and the script will fail with exactly this message, where xxx is the program or file that is expected:
'xxx' is not recognized as an internal or external command, operable program or batch file.This can be confusing because commands which are internal to the cmd environment (dir, cls, set, copy, move, etc) (list here) still continue to work in this situation.
You can debug a script where this is suspected by inserting the
pathcommand immediately before a problem line. The Windows path variable starts with these folders, and may be extended as programs are installed:%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem