Problems connecting a Windows 10 box to an AS/400 share and getting it to run a batch file











up vote
0
down vote

favorite












A few weeks ago we had an Windows XP box connected to an AS/400 network share mapped to drive P://. Batch files could be run from a remote call command from the 400. The batch files were called with a user password none / none.



We had to take the Windows XP box off the network suddenly without planning or the ability to get a replacement set before having to take it offline.



In comes an Windows 10 box. Due to the AS/400 not being on the domain, I have to map drive P:// with ./user and password. Everything is fine we have full control over folders and file, read, write, delete.



Drive P:// is where the AS/400 dumps HTML files for converting to PDF and then spooled - using a command line call to a Qindows program. gain everything was working on the XP box - but now all of a sudden the Windows 10 box seems like it has not authority to the P:// drive.



The user on logged in through AD is an administrator on the machine.



I have tried creating a ps-drive through PowerShell. It says that the execution policy restricts the action from being completed. Tried using credentials to log into the ps-drive and I can't get the prompt to take a ./ for the domain.



Standard batch files - run manually have access to the share through the drive letter but when I try to run the batch files through scheduled tasks it doesn't run seeming like it doesn't have access to the drive all of a sudden.



I've created a system link - but can't seem to get PowerShell to be able call the system link.



Basically what I need to do is after the HTML is created kick a batch file to convert to PDF and print - in an automated way.



I am stuck not understanding the security role issues between PowerShell and the drive - and the task scheduler and the drive.










share|improve this question




























    up vote
    0
    down vote

    favorite












    A few weeks ago we had an Windows XP box connected to an AS/400 network share mapped to drive P://. Batch files could be run from a remote call command from the 400. The batch files were called with a user password none / none.



    We had to take the Windows XP box off the network suddenly without planning or the ability to get a replacement set before having to take it offline.



    In comes an Windows 10 box. Due to the AS/400 not being on the domain, I have to map drive P:// with ./user and password. Everything is fine we have full control over folders and file, read, write, delete.



    Drive P:// is where the AS/400 dumps HTML files for converting to PDF and then spooled - using a command line call to a Qindows program. gain everything was working on the XP box - but now all of a sudden the Windows 10 box seems like it has not authority to the P:// drive.



    The user on logged in through AD is an administrator on the machine.



    I have tried creating a ps-drive through PowerShell. It says that the execution policy restricts the action from being completed. Tried using credentials to log into the ps-drive and I can't get the prompt to take a ./ for the domain.



    Standard batch files - run manually have access to the share through the drive letter but when I try to run the batch files through scheduled tasks it doesn't run seeming like it doesn't have access to the drive all of a sudden.



    I've created a system link - but can't seem to get PowerShell to be able call the system link.



    Basically what I need to do is after the HTML is created kick a batch file to convert to PDF and print - in an automated way.



    I am stuck not understanding the security role issues between PowerShell and the drive - and the task scheduler and the drive.










    share|improve this question


























      up vote
      0
      down vote

      favorite









      up vote
      0
      down vote

      favorite











      A few weeks ago we had an Windows XP box connected to an AS/400 network share mapped to drive P://. Batch files could be run from a remote call command from the 400. The batch files were called with a user password none / none.



      We had to take the Windows XP box off the network suddenly without planning or the ability to get a replacement set before having to take it offline.



      In comes an Windows 10 box. Due to the AS/400 not being on the domain, I have to map drive P:// with ./user and password. Everything is fine we have full control over folders and file, read, write, delete.



      Drive P:// is where the AS/400 dumps HTML files for converting to PDF and then spooled - using a command line call to a Qindows program. gain everything was working on the XP box - but now all of a sudden the Windows 10 box seems like it has not authority to the P:// drive.



      The user on logged in through AD is an administrator on the machine.



      I have tried creating a ps-drive through PowerShell. It says that the execution policy restricts the action from being completed. Tried using credentials to log into the ps-drive and I can't get the prompt to take a ./ for the domain.



      Standard batch files - run manually have access to the share through the drive letter but when I try to run the batch files through scheduled tasks it doesn't run seeming like it doesn't have access to the drive all of a sudden.



      I've created a system link - but can't seem to get PowerShell to be able call the system link.



      Basically what I need to do is after the HTML is created kick a batch file to convert to PDF and print - in an automated way.



      I am stuck not understanding the security role issues between PowerShell and the drive - and the task scheduler and the drive.










      share|improve this question















      A few weeks ago we had an Windows XP box connected to an AS/400 network share mapped to drive P://. Batch files could be run from a remote call command from the 400. The batch files were called with a user password none / none.



      We had to take the Windows XP box off the network suddenly without planning or the ability to get a replacement set before having to take it offline.



      In comes an Windows 10 box. Due to the AS/400 not being on the domain, I have to map drive P:// with ./user and password. Everything is fine we have full control over folders and file, read, write, delete.



      Drive P:// is where the AS/400 dumps HTML files for converting to PDF and then spooled - using a command line call to a Qindows program. gain everything was working on the XP box - but now all of a sudden the Windows 10 box seems like it has not authority to the P:// drive.



      The user on logged in through AD is an administrator on the machine.



      I have tried creating a ps-drive through PowerShell. It says that the execution policy restricts the action from being completed. Tried using credentials to log into the ps-drive and I can't get the prompt to take a ./ for the domain.



      Standard batch files - run manually have access to the share through the drive letter but when I try to run the batch files through scheduled tasks it doesn't run seeming like it doesn't have access to the drive all of a sudden.



      I've created a system link - but can't seem to get PowerShell to be able call the system link.



      Basically what I need to do is after the HTML is created kick a batch file to convert to PDF and print - in an automated way.



      I am stuck not understanding the security role issues between PowerShell and the drive - and the task scheduler and the drive.







      powershell windows-task-scheduler






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 21 at 0:28









      JakeGould

      30.7k1093135




      30.7k1093135










      asked Nov 21 at 0:07









      Kris.Mitchell

      1033




      1033






















          1 Answer
          1






          active

          oldest

          votes

















          up vote
          0
          down vote













          As for this...




          'It says that the execution policy restricts the action from being
          completed.'




          ... means your org is blocking PS use. If this is not a script action, you should be able to use any cmdlet interactive. You can check the execution policy by use the cmdlet...



          Get-ExecutionPolicy


          You can set the execution policy (if they are not blocking you changing it) by using the cmdlet..



          Set-ExecutionPolicy -ExecutionPolicy RemoteSigned


          Details here:



          # get function / cmdlet details
          (Get-Command -Name Get-ExecutionPolicy).Parameters
          Get-help -Name Get-ExecutionPolicy -Examples
          Get-help -Name Get-ExecutionPolicy -Full
          Get-help -Name Get-ExecutionPolicy -Online

          # get function / cmdlet details
          (Get-Command -Name Set-ExecutionPolicy).Parameters
          Get-help -Name Set-ExecutionPolicy -Examples
          Get-help -Name Set-ExecutionPolicy -Full
          Get-help -Name Set-ExecutionPolicy -Online


          As for this




          'I can't get the prompt to take a ./ for the domain.'




          No, you can't, you have to FQDN (servernamesharename) to the share. You don't need the domain. If you can ping the box / map to the share, then New-PSDrive should work. Yet, again, if they are blocking PS use cases, then that's all moot.



          # get function / cmdlet details
          (Get-Command -Name New-PSDrive).Parameters
          Get-help -Name New-PSDrive -Examples
          Get-help -Name New-PSDrive -Full
          Get-help -Name New-PSDrive -Online


          If you are saying, this means your local domain, you can just to this.



          # User short domain name
          $env:USERDOMAIN

          # Use FQDN
          $env:USERDNSDOMAIN


          As for this...




          'Standard batch files - run manually have access to the share through
          the drive letter but when I try to run the batch files through
          scheduled tasks it doesn't run seeming like it doesn't have access to
          the drive all of a sudden.'




          You need to ensure the credentials used for the Task are valid for the use case.



          With the exception of a hand full of PS cmdlets, if you are touching a remote machine using PSRemoting, you must be the admin on the target, this means logged on to your source host that is also the admin on the destination host, or be logged on as some other user and passing the correct admin creds to the destination.



          If you are saying, you are running a scheduled task from your source to the destination, then the same rules apply.



          If you are saying, you created a scheduled task on the destination, then, that is just using whatever proper creds you need on that host.



          Yet, again, if they are blocking PS holistically or just the ability to run scripts, then that is a whole different issue.



          The execution policy is not a security boundary, nor has MS ever said it was. It's just a way to prevent folks from stepping on their own toes. Unless they have gone through extraordinary effort to block PS use, the execution policy can be bypassed. There are lots of articles on the topic all over the web.



          Example of jus tone of them.




          https://blog.netspi.com/15-ways-to-bypass-the-powershell-execution-policy




          Just know, that if they enabled auditing of PS attempted use cases, that they have blocked, and you do this, it could result in negative actions for you. You know, those personal RPEs (Resume producing events)






          share|improve this answer





















          • "... means your org is blocking PS use." Not correct; configuring an execution policy does not block the use of PowerShell. Keep in mind that PowerShell's execution policy is an administrator safety feature, not a security feature.
            – Bill_Stewart
            22 hours ago













          Your Answer








          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "3"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1377138%2fproblems-connecting-a-windows-10-box-to-an-as-400-share-and-getting-it-to-run-a%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          up vote
          0
          down vote













          As for this...




          'It says that the execution policy restricts the action from being
          completed.'




          ... means your org is blocking PS use. If this is not a script action, you should be able to use any cmdlet interactive. You can check the execution policy by use the cmdlet...



          Get-ExecutionPolicy


          You can set the execution policy (if they are not blocking you changing it) by using the cmdlet..



          Set-ExecutionPolicy -ExecutionPolicy RemoteSigned


          Details here:



          # get function / cmdlet details
          (Get-Command -Name Get-ExecutionPolicy).Parameters
          Get-help -Name Get-ExecutionPolicy -Examples
          Get-help -Name Get-ExecutionPolicy -Full
          Get-help -Name Get-ExecutionPolicy -Online

          # get function / cmdlet details
          (Get-Command -Name Set-ExecutionPolicy).Parameters
          Get-help -Name Set-ExecutionPolicy -Examples
          Get-help -Name Set-ExecutionPolicy -Full
          Get-help -Name Set-ExecutionPolicy -Online


          As for this




          'I can't get the prompt to take a ./ for the domain.'




          No, you can't, you have to FQDN (servernamesharename) to the share. You don't need the domain. If you can ping the box / map to the share, then New-PSDrive should work. Yet, again, if they are blocking PS use cases, then that's all moot.



          # get function / cmdlet details
          (Get-Command -Name New-PSDrive).Parameters
          Get-help -Name New-PSDrive -Examples
          Get-help -Name New-PSDrive -Full
          Get-help -Name New-PSDrive -Online


          If you are saying, this means your local domain, you can just to this.



          # User short domain name
          $env:USERDOMAIN

          # Use FQDN
          $env:USERDNSDOMAIN


          As for this...




          'Standard batch files - run manually have access to the share through
          the drive letter but when I try to run the batch files through
          scheduled tasks it doesn't run seeming like it doesn't have access to
          the drive all of a sudden.'




          You need to ensure the credentials used for the Task are valid for the use case.



          With the exception of a hand full of PS cmdlets, if you are touching a remote machine using PSRemoting, you must be the admin on the target, this means logged on to your source host that is also the admin on the destination host, or be logged on as some other user and passing the correct admin creds to the destination.



          If you are saying, you are running a scheduled task from your source to the destination, then the same rules apply.



          If you are saying, you created a scheduled task on the destination, then, that is just using whatever proper creds you need on that host.



          Yet, again, if they are blocking PS holistically or just the ability to run scripts, then that is a whole different issue.



          The execution policy is not a security boundary, nor has MS ever said it was. It's just a way to prevent folks from stepping on their own toes. Unless they have gone through extraordinary effort to block PS use, the execution policy can be bypassed. There are lots of articles on the topic all over the web.



          Example of jus tone of them.




          https://blog.netspi.com/15-ways-to-bypass-the-powershell-execution-policy




          Just know, that if they enabled auditing of PS attempted use cases, that they have blocked, and you do this, it could result in negative actions for you. You know, those personal RPEs (Resume producing events)






          share|improve this answer





















          • "... means your org is blocking PS use." Not correct; configuring an execution policy does not block the use of PowerShell. Keep in mind that PowerShell's execution policy is an administrator safety feature, not a security feature.
            – Bill_Stewart
            22 hours ago

















          up vote
          0
          down vote













          As for this...




          'It says that the execution policy restricts the action from being
          completed.'




          ... means your org is blocking PS use. If this is not a script action, you should be able to use any cmdlet interactive. You can check the execution policy by use the cmdlet...



          Get-ExecutionPolicy


          You can set the execution policy (if they are not blocking you changing it) by using the cmdlet..



          Set-ExecutionPolicy -ExecutionPolicy RemoteSigned


          Details here:



          # get function / cmdlet details
          (Get-Command -Name Get-ExecutionPolicy).Parameters
          Get-help -Name Get-ExecutionPolicy -Examples
          Get-help -Name Get-ExecutionPolicy -Full
          Get-help -Name Get-ExecutionPolicy -Online

          # get function / cmdlet details
          (Get-Command -Name Set-ExecutionPolicy).Parameters
          Get-help -Name Set-ExecutionPolicy -Examples
          Get-help -Name Set-ExecutionPolicy -Full
          Get-help -Name Set-ExecutionPolicy -Online


          As for this




          'I can't get the prompt to take a ./ for the domain.'




          No, you can't, you have to FQDN (servernamesharename) to the share. You don't need the domain. If you can ping the box / map to the share, then New-PSDrive should work. Yet, again, if they are blocking PS use cases, then that's all moot.



          # get function / cmdlet details
          (Get-Command -Name New-PSDrive).Parameters
          Get-help -Name New-PSDrive -Examples
          Get-help -Name New-PSDrive -Full
          Get-help -Name New-PSDrive -Online


          If you are saying, this means your local domain, you can just to this.



          # User short domain name
          $env:USERDOMAIN

          # Use FQDN
          $env:USERDNSDOMAIN


          As for this...




          'Standard batch files - run manually have access to the share through
          the drive letter but when I try to run the batch files through
          scheduled tasks it doesn't run seeming like it doesn't have access to
          the drive all of a sudden.'




          You need to ensure the credentials used for the Task are valid for the use case.



          With the exception of a hand full of PS cmdlets, if you are touching a remote machine using PSRemoting, you must be the admin on the target, this means logged on to your source host that is also the admin on the destination host, or be logged on as some other user and passing the correct admin creds to the destination.



          If you are saying, you are running a scheduled task from your source to the destination, then the same rules apply.



          If you are saying, you created a scheduled task on the destination, then, that is just using whatever proper creds you need on that host.



          Yet, again, if they are blocking PS holistically or just the ability to run scripts, then that is a whole different issue.



          The execution policy is not a security boundary, nor has MS ever said it was. It's just a way to prevent folks from stepping on their own toes. Unless they have gone through extraordinary effort to block PS use, the execution policy can be bypassed. There are lots of articles on the topic all over the web.



          Example of jus tone of them.




          https://blog.netspi.com/15-ways-to-bypass-the-powershell-execution-policy




          Just know, that if they enabled auditing of PS attempted use cases, that they have blocked, and you do this, it could result in negative actions for you. You know, those personal RPEs (Resume producing events)






          share|improve this answer





















          • "... means your org is blocking PS use." Not correct; configuring an execution policy does not block the use of PowerShell. Keep in mind that PowerShell's execution policy is an administrator safety feature, not a security feature.
            – Bill_Stewart
            22 hours ago















          up vote
          0
          down vote










          up vote
          0
          down vote









          As for this...




          'It says that the execution policy restricts the action from being
          completed.'




          ... means your org is blocking PS use. If this is not a script action, you should be able to use any cmdlet interactive. You can check the execution policy by use the cmdlet...



          Get-ExecutionPolicy


          You can set the execution policy (if they are not blocking you changing it) by using the cmdlet..



          Set-ExecutionPolicy -ExecutionPolicy RemoteSigned


          Details here:



          # get function / cmdlet details
          (Get-Command -Name Get-ExecutionPolicy).Parameters
          Get-help -Name Get-ExecutionPolicy -Examples
          Get-help -Name Get-ExecutionPolicy -Full
          Get-help -Name Get-ExecutionPolicy -Online

          # get function / cmdlet details
          (Get-Command -Name Set-ExecutionPolicy).Parameters
          Get-help -Name Set-ExecutionPolicy -Examples
          Get-help -Name Set-ExecutionPolicy -Full
          Get-help -Name Set-ExecutionPolicy -Online


          As for this




          'I can't get the prompt to take a ./ for the domain.'




          No, you can't, you have to FQDN (servernamesharename) to the share. You don't need the domain. If you can ping the box / map to the share, then New-PSDrive should work. Yet, again, if they are blocking PS use cases, then that's all moot.



          # get function / cmdlet details
          (Get-Command -Name New-PSDrive).Parameters
          Get-help -Name New-PSDrive -Examples
          Get-help -Name New-PSDrive -Full
          Get-help -Name New-PSDrive -Online


          If you are saying, this means your local domain, you can just to this.



          # User short domain name
          $env:USERDOMAIN

          # Use FQDN
          $env:USERDNSDOMAIN


          As for this...




          'Standard batch files - run manually have access to the share through
          the drive letter but when I try to run the batch files through
          scheduled tasks it doesn't run seeming like it doesn't have access to
          the drive all of a sudden.'




          You need to ensure the credentials used for the Task are valid for the use case.



          With the exception of a hand full of PS cmdlets, if you are touching a remote machine using PSRemoting, you must be the admin on the target, this means logged on to your source host that is also the admin on the destination host, or be logged on as some other user and passing the correct admin creds to the destination.



          If you are saying, you are running a scheduled task from your source to the destination, then the same rules apply.



          If you are saying, you created a scheduled task on the destination, then, that is just using whatever proper creds you need on that host.



          Yet, again, if they are blocking PS holistically or just the ability to run scripts, then that is a whole different issue.



          The execution policy is not a security boundary, nor has MS ever said it was. It's just a way to prevent folks from stepping on their own toes. Unless they have gone through extraordinary effort to block PS use, the execution policy can be bypassed. There are lots of articles on the topic all over the web.



          Example of jus tone of them.




          https://blog.netspi.com/15-ways-to-bypass-the-powershell-execution-policy




          Just know, that if they enabled auditing of PS attempted use cases, that they have blocked, and you do this, it could result in negative actions for you. You know, those personal RPEs (Resume producing events)






          share|improve this answer












          As for this...




          'It says that the execution policy restricts the action from being
          completed.'




          ... means your org is blocking PS use. If this is not a script action, you should be able to use any cmdlet interactive. You can check the execution policy by use the cmdlet...



          Get-ExecutionPolicy


          You can set the execution policy (if they are not blocking you changing it) by using the cmdlet..



          Set-ExecutionPolicy -ExecutionPolicy RemoteSigned


          Details here:



          # get function / cmdlet details
          (Get-Command -Name Get-ExecutionPolicy).Parameters
          Get-help -Name Get-ExecutionPolicy -Examples
          Get-help -Name Get-ExecutionPolicy -Full
          Get-help -Name Get-ExecutionPolicy -Online

          # get function / cmdlet details
          (Get-Command -Name Set-ExecutionPolicy).Parameters
          Get-help -Name Set-ExecutionPolicy -Examples
          Get-help -Name Set-ExecutionPolicy -Full
          Get-help -Name Set-ExecutionPolicy -Online


          As for this




          'I can't get the prompt to take a ./ for the domain.'




          No, you can't, you have to FQDN (servernamesharename) to the share. You don't need the domain. If you can ping the box / map to the share, then New-PSDrive should work. Yet, again, if they are blocking PS use cases, then that's all moot.



          # get function / cmdlet details
          (Get-Command -Name New-PSDrive).Parameters
          Get-help -Name New-PSDrive -Examples
          Get-help -Name New-PSDrive -Full
          Get-help -Name New-PSDrive -Online


          If you are saying, this means your local domain, you can just to this.



          # User short domain name
          $env:USERDOMAIN

          # Use FQDN
          $env:USERDNSDOMAIN


          As for this...




          'Standard batch files - run manually have access to the share through
          the drive letter but when I try to run the batch files through
          scheduled tasks it doesn't run seeming like it doesn't have access to
          the drive all of a sudden.'




          You need to ensure the credentials used for the Task are valid for the use case.



          With the exception of a hand full of PS cmdlets, if you are touching a remote machine using PSRemoting, you must be the admin on the target, this means logged on to your source host that is also the admin on the destination host, or be logged on as some other user and passing the correct admin creds to the destination.



          If you are saying, you are running a scheduled task from your source to the destination, then the same rules apply.



          If you are saying, you created a scheduled task on the destination, then, that is just using whatever proper creds you need on that host.



          Yet, again, if they are blocking PS holistically or just the ability to run scripts, then that is a whole different issue.



          The execution policy is not a security boundary, nor has MS ever said it was. It's just a way to prevent folks from stepping on their own toes. Unless they have gone through extraordinary effort to block PS use, the execution policy can be bypassed. There are lots of articles on the topic all over the web.



          Example of jus tone of them.




          https://blog.netspi.com/15-ways-to-bypass-the-powershell-execution-policy




          Just know, that if they enabled auditing of PS attempted use cases, that they have blocked, and you do this, it could result in negative actions for you. You know, those personal RPEs (Resume producing events)







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 23 at 23:20









          postanote

          83513




          83513












          • "... means your org is blocking PS use." Not correct; configuring an execution policy does not block the use of PowerShell. Keep in mind that PowerShell's execution policy is an administrator safety feature, not a security feature.
            – Bill_Stewart
            22 hours ago




















          • "... means your org is blocking PS use." Not correct; configuring an execution policy does not block the use of PowerShell. Keep in mind that PowerShell's execution policy is an administrator safety feature, not a security feature.
            – Bill_Stewart
            22 hours ago


















          "... means your org is blocking PS use." Not correct; configuring an execution policy does not block the use of PowerShell. Keep in mind that PowerShell's execution policy is an administrator safety feature, not a security feature.
          – Bill_Stewart
          22 hours ago






          "... means your org is blocking PS use." Not correct; configuring an execution policy does not block the use of PowerShell. Keep in mind that PowerShell's execution policy is an administrator safety feature, not a security feature.
          – Bill_Stewart
          22 hours ago




















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Super User!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.





          Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


          Please pay close attention to the following guidance:


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1377138%2fproblems-connecting-a-windows-10-box-to-an-as-400-share-and-getting-it-to-run-a%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          AnyDesk - Fatal Program Failure

          How to calibrate 16:9 built-in touch-screen to a 4:3 resolution?

          QoS: MAC-Priority for clients behind a repeater