This topic contains 7 replies, has 4 voices, and was last updated by
July 11, 2019 at 12:56 pm #165328
We have installed a new Windows server and Move-Item is not functioning. I believe the issue to be firewall related and would like to know what Protocols and TCP ports Move-Item uses.
July 11, 2019 at 2:36 pm #165343ParticipantTopics: 1Replies: 59Points: 328Rank: Contributor
When you say its not working...are you getting an error message? What's the code you're executing. Depending on how you write it can use SMB or the WinRM ports.
This link will show you to use WinRM (ala invoke-command) to copy files.
July 15, 2019 at 4:54 pm #166063
I was going to try this without "Plowing Corn", but seeing your question, here goes:
The Error message returned is: "move-item : The specified network name is no longer available."
Get same error with Copy-Item also. Our corporate security group tells me that they have port: SMB/CIFS TCP port 445 Open point to point.
The source server is physical Windows Server 2016. The Destination is a Hitachi HNAS unit with this specific share presented as Both: NFS and SMB.
What is really Odd is that using: Windows File Explorer on the Source server, I can access the Destination share. I can store, retrieve, and delete files.
So I believe our internal Firewall has SMB open. Evidently Move-Item Must be using a different protocol. I will read the post/blog link that you sent me. Thanks for that. Any additional thoughts?
Missed your Question on what code I'm Running. For debugging purposes I have this down to a simple command entered from in a PowerShell window as follows. Only the company specific information has been changed for this posting:
PS C:\Users\mylog> move-item -Path F:\LOCAL-SOURCE\admin\Test_Move_File.txt -Destination \\DEST-SERVER\data01_storage\OCA\MyMyMy.csv -Force
Also I've read the Blog post that you sent. Don't think that will help as the Destination is a NAS box and not a Windows Server.
July 16, 2019 at 9:34 pm #166322ParticipantTopics: 1Replies: 59Points: 328Rank: Contributor
That is odd, I don't have any experience moving files to a straight NAS, so for now I'm going to ignore that.
Does the path exist up to the file?
Copy-item(and move-item) doesn't like to create folders if you're only copying a file.
you could try:
new-item \\DEST-SERVER\data01_storage\OCA\MyMyMy.csv -Force
That will create a 0 byte file BUT it will create the directory structure. Then try to copy/move the file to the destination
July 29, 2019 at 8:03 pm #168385
Thanks for your quick reply and my slow follow-up.
Yes. the directory exists. Every day, through the Windows Task Scheduler, this script is kicked off at a specific time to coincide with the landing of a freshly run report file, that is moved to the directory on the destination server.
I have inherited this Powershell script from a colleague that has moved on. This thing has been (and would continue if I let it) working for years on another machine. We have upgraded hardware and from Windows 2008 to Windows 2016. I understand that our security folks are clamping down on firewall settings when new equipment is rolled out, which is why I'm looking for port number and protocols utilized by: Move_item.
The report generator creates a text file (.csv) with a complex name that includes Date/Time. The Powershell script looks for the complex name with the current date and moves it to the File Share with a Fixed name. the Force parameter is added to permit overwriting the existing file.
If the port/protocol path that I'm on is a dead-end, does anyone know of any functional changes in Move-item between Windows 2008 and Windows 2016?
Thanks in advance for anyone's input...
August 1, 2019 at 6:00 am #168934ParticipantTopics: 2Replies: 999Points: 1,946Rank: Community Hero
' The specified network name is no longer available.'
… has noting to do with Powershell or the cmdlets you are trying to leverage for your use case.
This a very common error in Windows proper and there are many posts that talk to that error, and those posts again, are not PowerShell specific. That error can be caused by just about anything, but the major culprit are Nic configs (especially teamed or multi-nic systems), other gateways, IDAM / filtering endpoints up / down stream, firewalls, yaddda, yadda, yadda.
I've hit this thing far too many time, well before PowerShell (aka Monad) was ever a thing.
Just take the string and do a quick search to see what I mean.
August 1, 2019 at 2:34 pm #169021
Thank You for your quick reply and for the links. I will go through them this morning. We are running Teamed 10Gb Ethernet Ports, so I'll start there.
Didn't think this would be a Power Shell issue, I started this post just looking for what TCP ports/Protocols Move-Item would use... Our Corporate Security Guys have really tighten down the firewall for new installs.
One item that might help with debugging, is there a way to redirect Standard Error and Standard Out to a file as one can with Unix?
Thanks in advance!
August 1, 2019 at 4:12 pm #169039ParticipantTopics: 2Replies: 483Points: 1,154Rank: Community Hero
As long as it's done within PowerShell, yep. Separate files, or the same file?
Invoke-Script 2>&1 > "c:\path\to\logfile"
Invoke-Script > "c:\path\to\logfile" 2> "c:\path\to\errorlog"
You must be logged in to reply to this topic.