In general, there should be no problem importing new drivers and driver packages to SCCM, as long as you follow a simple rule – whatever you import – do not move or modify the driver source files.
The reason for this is simple – when you import another driver pack or series of drivers, and it includes also a driver that was imported to SCCM before, but has been moved (or deleted!), you will not be able to use nor import the “broken” driver.
When this happens, if we are talking about a few of these corrupted ones, it might be easier to find them in SCCM, delete them from there and let them import again, this time with no errors.
However, if we are talking about huge number of drivers, and these are also already in use for multiple driver packages (and even models perhaps), or you moved the whole driver source location, you might find following method handy to workaround the issue.
You simple extract and prepare the driver package to your driver package source, create a batch (.cmd) file and name it whatever you want (I like to use the driver package name/version from vendor – so for example tp_x140e_w1064_201509.cmd):
@ECHO OFF
for /f "tokens=*" %%G IN ('dir /ad /b /s') DO (
echo. > "%%G\%~n0.txt"
) When you run the batch file, it will create a blank text file name according the script name you gave it, in each folder and sub folder from the root of the package. This by no means harms the package, but is sufficient to “confuse” the SCCM’s import mechanics to regard each driver as a unique one – and thus importing them as duplicates.
Beware that this is not really super-efficient solution in long term – when used regularly – it floods the SCCM with duplicate drivers and also increases the imported driver package folder – the ones that are stored on each distribution points.