So, I am trying to make a PowerShell scripted backup of our documentation, solutions, and white papers to a windows server which can be easily accessed
Unfortunately, when I download them I am unable to name the articles and attachments by their long names.
I did attempt a workaround, which somewhat works in some places, where I download the webpage and attachments and just do a Get-ChildItem "$ItemOriginalfilepath" | Rename-Item -NewName "$ItemFullNameWithExtension" -Force and that works for one location, I don't know why.
My main issue is how do I rename the file in other windows servers, where this trick seems to NOT work.
How do I overcome that 260 limit for renaming or maybe in general?
You can tweak GPO or registry to overcome 260 character limits, but since there are no details in your question I am not sure if it'll help.
AFAIK it works in Windows 10 and Windows Server 2016. You will need GPO templates to make it available on windows server 2012r2
This article is pretty useful
https://www.saotn.org/ntfs-long-paths-windows-server-2016-gpo/
Please have a look at this question and answer.
https://serverfault.com/questions/847142/cant-use-long-path-names-in-windows-2016
Related
first I want to state that I am a novice when it comes to code/programming. Also, I have a Mac (that runs Catalina, if that matters).
This is my first time posting to this forum, so please forgive any missteps in protocol...
Here's some background info to my question:
I have Microsoft 365 for Business and I use Teams. I'm a small business and I'm the owner and administrator. I need to be able to share externally with anyone. I have changed the settings in SharePoint admin and OneDrive admin to be able to share externally. Look here to see an example of what I have done, and the problem: https://techcommunity.microsoft.com/t5/onedrive-for-business/share-with-anyone-with-the-link-setting-is-grey-out-why/m-p/810390
Even after allowing for external sharing, the sharing options are still greyed-out. But this is not my question. I know how to fix it; as it says in the above link, I need to enable sharing in Powershell via set-sposite "siteurl" -sharingcapability ExternalUserAndGuestSharing
After some research, I found that there is a Microsoft Pwsh for Mac. I downloaded Homebrew, Microsoft PowerShell and Azure. (I also have Node.js, if that matters.) Here is a screenshot of my terminal (I hid any identifying information...):
terminal screenshot
As you can see, I get this error: Connect-SPOService -Url https://<organization name here>admin.sharepoint.com Connect-SPOService: The term 'Connect-SPOService' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
I contacted Microsoft and had a technician with me on the phone trying to troubleshoot their way into my SPOService on my Mac using Homebrew in order to fix the greyed-out "share with anyone" option. We were unsuccessful. At the moment, I do have access to a Windows computer, and I was able to enter my SPOService on that Windows computer and resolve the problem. However, for each new SharePoint site I create and want to share externally, I will need to repeat this process (at least, this is what the technician told me). I will not always have access to a Windows computer, therefore I need to be able to enter my SPOService on my Macbook.
Are there any workarounds? Is there an SPOService powershell for Mac? If I have the pswh for Microsoft, why won't it let me into sharepoint?
Thank you in advance for any assistance
First, I can still not rename the domain, but I can help you with a general SharePoint update. It does not work either in Azure or on Mac OX X.
If you like to check, repeat the following steps on your computer setup, assuming you don't use a Windows Computer.
Check the availability of SharePoint
Get-Module -Name Microsoft.Online.SharePoint.PowerShell -ListAvailable | Select Name,Version
Install the module if missing
On a mac with the name of your user directory
Import-Module /Users/username/.local/share/powershell/Modules Microsoft.Online.SharePoint.PowerShell -Verbose
On Azure Powershell
Import-Module Microsoft.Online.SharePoint.PowerShell -Verbose
You get a PowerShell via a one-month Test-Subscription.
Prepare your Admin URL
$AdminCenterURL="https://name_you_used_during_first_setup-admin.sharepoint.com"
Make sure you add "-admin" at the end of your domain name. You received this when you signed up. It is not the domain name you can use for your subscription later; it's, unfortunately, how Microsoft decided to implement it. Therefore, changing from Mac or Azure is not possible.
Connect to your side
Connect-SPOService -Url $AdminCenterURL -Credential (Get-Credential)
And now it will fail with
Connect-SPOService: The type initializer for 'Microsoft.Win32.Registry' threw an exception.
Unfortunately, after exchanging many emails with Microsoft, I could not resolve this with the Support desk. However, the error seems to be known.
I wrote this note to allow others to save valuable time so that somebody would not waste his time if they tried to resolve it as I tried.
If like me, you are stuck with renaming the initial SharePoint subdomain, you currently have the following options.
Buy a Windows PC with a License or install a VM with a MS Windows trial license
Buy an Enterprise License, and use the Beta functionality.
Delete your subscription, but then you might lose the active licenses and the work you have put in already. But you can re-register, and this time put the name into the subscription, which you like to see as a subdomain of SharePoint. But you lose all work put in, in the first place.
Not really sure of my exact question, but here is the situation:
I have an application (WinForms, C# .Net) that I am developing in Visual Studio 2012. It does a lot of things but the important bit is that it needs to read files from a certain location.
In this case, the location of the files is on a server and my machine has a mapped network drive setup for accessing the files. I can manually navigate to the files with Windows Explorer fine.
I have the following line in my code which is highlighting the issue:
System.IO.File.Exists("X:\\A Folder\\a_file.txt");
And that file does exist in that location. However this is where the problem occurs: if I build the solution and run the .exe directly from the "bin" folder (double-click). The code is fine, and it finds the file. But if I run it with visual studio then I get a "file not found" exception.
I am putting this down to the fact that Visual Studio is running in "Administrator" mode (I forget why I needed this, but I do). Now this makes sense if you consider that the "administrator" account does not have the "X:\" drive mapped. However, this has never been a problem until I upgraded to Windows 10 last week.
So my question is:
Does Visual Studio Administrator mode work differently in Windows 10? In this case, does it handle mapped network drives differently?
It's worth noting I upgraded from Windows 7, so I cannot confirm if this issue is also present in 8 and 8.1 or not.
And before anyone asks, let's just say it has to be a mapped drive. No UNC paths allowed!
So I have found a solution/workaround. Kind of seems like a wasted bounty now, so if someone has other suggestions that are better then please post and I will review them and award as applicable. Or even if somebody can make a more detailed version of my solution then I will award that one.
The issue is probably not specific to Visual Studio, but would occur with any application running with elevated privileges. Anyway, the solution I found is to add a registry key that enables the same shared drives to be accessible when running in administrator mode.
The registry key location is:
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Policies/System
And the key to add is called:
EnableLinkedConnections
And should be created as a DWORD with a value of 1 (0x00000001)
I checked with the machines running Windows 7 and they do NOT have this key, yet they still work fine. So I expect this isn't the only solution, but it does seem to work (no side effects noted yet). I would assume that Windows 10 has a specific setting somewhere that by default prevents mapped drives from automatically being available with "run as administrator".
For reference, I found this information here.
In fact, here is a more "official" recommendation for using this reg key.
This is unlikely to have anything to do with Windows 10, just with the configuration of your machine. What you describe is normal and covered by this KB article. Nothing I can check for myself so just try the recommended workarounds, follow up at superuser.com if necessary.
Different users/system tasks maybe running. As such, you have the X drive mapped, but others do not. You could do the drive mapping on additional users on your Windows installation as well. As you stated, this should not be a Windows 10 only issue, but also Windows 7+ and elevated privileges.
Maybe you could use a configured parameter for the X: path and load at runtime, or even try using UNC paths which will resolve at runtime and not need the drive to be mapped.
\\ServerNameOrIP\A Folder\a_file.txt.
In the code, you would need:
System.IO.File.Exists("\\\\ServerName\\A Folder\\a_file.txt");
I've been asked to update a VB6 application that's been running on WinXP for the last 6 years. The client wants to use Windows 7. Up until now, the app stored its settings in an INI file located in the application directory. One key difference between XP and 7 is that you can't write to C:\Program Files\AppFolder anymore.
I am trying to figure out where on the file system should I store settings? Given that the application is still required to run on WinXP, I am kind of confused.
On WinXP, I have the following:
C:\Documents and Settings\profilename\Application Data
C:\Documents and Settings\profilename\Local Settings\Application Data
On Windows 7, I have the following:
C:\Users\profilename\AppData\Local
C:\Users\profilename\AppData\LocalLow
C:\Users\profilename\AppData\Roaming
Each one of these folders have subfolders that seem to store settings/files for various products
So 2 questions:
Given all these folders, where do I store my settings?
I am assuming that there is a nifty Windows API call that would give me the proper location of this folder. And I am hoping it works on both XP and 7. Is my assumption correct? If so, a link would be much appreciated.
There are a number of special folders you can use, on XP/Vista/Windows 7:
The CSIDL_APPDATA folder is the one you will likely be most interested in. Data stored here is available to roaming users at whatever machine they log in to. This is the best place to store simple configuration data. All users have write access to this (and the last) folder. Note that none of the above folders are for user-generated data! That would properly belong under the My Documents hierarchy.
EDIT: As Cody Gray suggests in the comments, also consider CSIDL_LOCAL_APPDATA for application data that will always be local to the current machine, but is set aside on a per user basis. The data in this folder is not available on a roaming basis, so it should be data that the user will likely not miss if they log in to a different machine.
I shamelessly copied the explanation above from a good article by Karl Peterson, explaining this for VB6 programmers. Karl also has a ready-to-use class that will help you find the directories, but IMHO he's overcomplicated things this time. Bob Riemersma has a better way in one line, using the Shell object, as below. EDIT Bob's comment below explains why it's best to use late binding for this rather than early binding.
Const ssfCOMMONAPPDATA = &H23
Const ssfLOCALAPPDATA = &H1c
Const ssfAPPDATA = &H1a
Dim strAppData As String
strAppData = _
CreateObject("Shell.Application").NameSpace(ssfAPPDATA).Self.Path
In my opinion it's fine to continue to use INI files in these directories.
See the question "Does Microsoft have a best practices document regarding the storage of app data?" for some helpful info.
Maybe you just save your settings in Windows Registry?
That's very easy. Using SaveSeting and GetSetting is much easier than creating INI file.
And there is no trouble in compatibility, from WinNT to Windows 8.
I am attempting to decompress a .gz file using the GnuWin32 gzip program in Windows 7. I have full permissions on the compressed file, and my user account is an administrator. However, I end up not having read permissions on the decompressed file. To get read permissions I would have to manually change the permissions on it through right-clicking and selecting Properties > Security. I am able to do this exact same thing with no permission problems in Windows XP, which leads me to believe that Windows 7's user account control system is causing problems. Does anyone know what I can do to make things work as I would expect (read permission on the decompressed file) in Windows 7?
Thanks.
Is there some reason you need to use GnuWin32? I highly recommend 7-zip, even more than WinRAR. It's free, and I use it for everything, even ISOs. There's hardly anything it won't archive or decompress properly. I generally use the .tar.gz format with it :)
One note, if you're on x64, use the x64 version. Some people have been known to experience bugginess using the x86 on x64 Windows.
I'll assume this is an answer since I know for a fact it will deal with your permissions issues, and since you didn't specify any reason why you needed to use the other app. Cheers! :)
I re-image one of my machines regularly; and have a script that I run after the OS install completes to configure my machine; such that it works how I like.
I happen to have my data on another drive...and I'd like to add code to my script to change the location of the Documents directory from "C:\Users\bryansh\Documents" to "D:\Users\bryansh\Documents".
Does anybody have any insight, before I fire up regmon and really roll up my sleeves?
I use reparse points http://www.hanselman.com/blog/MoreOnVistaReparsePoints.aspx to redirect My Documents.
SHSetFolderPath Function should help, since this article mentions its use for folder redirection by the Group Policy API.