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

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.

Answer 1

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 (servername\sharename) 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)