Question on Move-Item Internals

Welcome Forums General PowerShell Q&A Question on Move-Item Internals

This topic contains 7 replies, has 4 voices, and was last updated by

 
Participant
1 month, 3 weeks ago.

  • Author
    Posts
  • #165328

    Participant
    Topics: 1
    Replies: 3
    Points: 44
    Rank: Member

    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.

    Any Help?

    Thanks,

    -Steve

  • #165343

    Participant
    Topics: 1
    Replies: 59
    Points: 328
    Helping Hand
    Rank: 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.

    https://blog.ipswitch.com/use-powershell-copy-item-cmdlet-transfer-files-winrm

    • #166063

      Participant
      Topics: 1
      Replies: 3
      Points: 44
      Rank: Member

      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?

      -Steve

      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.

      -Steve

       

    • #166322

      Participant
      Topics: 1
      Replies: 59
      Points: 328
      Helping Hand
      Rank: 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?

      \\DEST-SERVER\data01_storage\OCA\

       

      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

       

  • #168385

    Participant
    Topics: 1
    Replies: 3
    Points: 44
    Rank: Member

    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...

    -Steve

  • #168934

    Participant
    Topics: 2
    Replies: 999
    Points: 1,946
    Helping Hand
    Rank: Community Hero

    This ...

    ' 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.

    Example(s):

    https://support.microsoft.com/en-us/help/961293/unable-to-access-shares-the-specified-network-name-is-no-longer-availa

    https://community.spiceworks.com/topic/239423-the-specified-network-name-is-no-longer-available-while-writing-to-shared-dir

    https://www.tenforums.com/network-sharing/67299-specified-network-name-no-longer-available.html

     

     

     

     

     

  • #169021

    Participant
    Topics: 1
    Replies: 3
    Points: 44
    Rank: Member

    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!

  • #169039

    Participant
    Topics: 2
    Replies: 483
    Points: 1,154
    Helping Hand
    Rank: Community Hero

    As long as it's done within PowerShell, yep. Separate files, or the same file?

    Same file:

    Invoke-Script 2>&1 > "c:\path\to\logfile"

    Separate files:

    Invoke-Script > "c:\path\to\logfile" 2> "c:\path\to\errorlog"

You must be logged in to reply to this topic.