'CreateDirectory Failed' -2147467259 Publishing Error

'CreateDirectory Failed' -2147467259 Publishing Error

Summary

"CreateDirectory Failed" error is a generic error that may be caused by multiple scenarios. Such a scenario can be moving the default for WSUS \UpdateServicesPackages\ directory physically to another drive or server without using WsusUtil.exe to register the change.

It may also occur due to failure to utilize more disc space to create folder and place files in it on the WSUS, or even permission-related causes can force this error to occur.

Symptoms

SVM2018 is connecting nicely to the WSUS Alias name you've configured in the domain.
Nevertheless, the SPS fails to publish the package with error 'CreateDirectory Failed' -2147467259.

Here's what usually happens:

  • Your account is sufficient to do the publishing job, and your WSUS is in perfect health.
  • The WSUS\UpdateServicesPackages folder has enough free disk space and there is no file system permission blocking occurring.
  • Your code-signing certificates are in perfect order installed as per SVM2018 requirements.
  • You are connecting to WSUS from inside SVM2018 using an Alias DNS name and not the FQDN of the server.
  • SVM2018 is connecting to WSUS via SSL.
    • The SSL certificate used for the WSUS connection was 'Issued To' the alias server name.
  • The csi_pluginlog.txt file captures the following error description that explains the problem:
"Failed to create package: : -2147352567 , In 'Publisher.invoke'
Code: -2147467259
CreateDirectory failed
--> System.ComponentModel.Win32Exception (0x80004005): CreateDirectory failed
at Microsoft.UpdateServices.Internal.FileSystemUtilities.CreateDirectory(String path)
at Microsoft.UpdateServices.Internal.BaseApi.Publisher.VerifyAndPublishPackage()
at Microsoft.UpdateServices.Internal.BaseApi.Publisher.PublishPackage(String sourcePath, String additionalSourcePath, String packageDirectoryName, Boolean dualSign, String httpTimeStamp)
at Microsoft.UpdateServices.Internal.BaseApi.Publisher.PublishPackage(String sourcePath, String additionalSourcePath, String packageDirectoryName)
at plugin.DotNetWrapper<Microsoft::UpdateServices::Administration::IPublisher>.invoke(DotNetWrapper<Microsoft::UpdateServices::Administration::IPublisher>* , PluginBstr* name, Arguments* args, PluginMarshal* marshal)"
  • When it fails to publish, the SVM2018 displays this error:

User-added image

Cause

This article looks at a slightly more complicated scenario where the error is caused by the use of DNS Alias Name used in the WSUS/SCCM (Disconnected) in preference of using the server FQDN.

What happens when SVM2018 is connecting to WSUS using the Alias DNS name instead of the actual server name?

  • You are connecting SVM2018 to WSUS using the DNS Alias name of your update server instead of using its fully qualified server name.
  • SVM2018 and WSUS connect nicely because:
    • The domain DNS Server is forwarding the Alias name query correctly to the WSUS server IP.
    • The SSL certificate used for the required SSL-binding at the IIS server is 'Issued To' the same Alias name that you input in the SVM2018 connection window.
    • SVM2018 matches the name you input to the DNS Alias entry and can further match the SSL-certificate 'Issued To' field to the name it has in its settings.

Why is such a scenario problematic to publish packages?

  • SVM2018 uses the 'Server Name string' you input in the connection box under Patching > WSUS/SCCM (Disconnected) to upload packages to WSUS.
  • It takes the string and formats it in UNC path formatting to be able to utilize the underlying file system to transfer the file to the server.
  • When alias name is used i.e. aliaswsusname.mydomain.com, SVM2018 is creating a request to upload the file at \\aliaswsusname.mydomain.com
    • Since the Alias name is not the real server name, the UNC formatting fails.
    • \\aliaswsusname.mydomain.com is \\realwsusname.mydomain.com which is while the package upload fails to 'Create Directory'.

Resolution

To resolve this issue, you shall take the following steps:

  • Create a new SSL certificate with purpose 'Server and Client Authentication' that is 'Issued To' the FQDN of WSUS (you may include additional 'Issued To' recipient Aliases to it!).
  • Accommodate the new SSL certificate by:
    • Removing the old SSL certificate that was issued to the Alias name.
    • Make new 'Binding' using the new SSL certificate on the WSUS Administration Site
    • In the 'Edit Site Bindings', you should input the FQDN of the server under the 'Host Name' field.

User-added image

  • Run CMD as admin and browse to the directory C:\Program Files\Update Services\Tools
    • Run WsusUtil.exe configuressl <Fully Qualified Server Name>.
    • The output should be similar as shown in the example below.

User-added image

  • Import the Private-Key SSL-certificate at the 'Personal' certificate store (via MMC) and the Public-Key-Only cert to 'Trusted Root Certification Authorities' and 'Trusted Publishers' stores.
  • Enter the SVM2018 Interface and reconnect to WSUS using the FQDN of your server (do not use the DNS Alias name) and the secure connection port you configured at the IIS server.
  • Publish a package.
Was this article helpful? Yes No
No ratings
Version history
Revision #:
2 of 2
Last update:
‎Sep 16, 2019 04:15 PM
Updated by:
 
Contributors