These changes are only applicable to users in the EEA. For those outside the region, Windows will continue to function as it is!

The changes to Windows for DMA-compliance include:

  • You can now uninstall Edge and Bing web search using the built-in settings. Earlier, the option was greyed out.
  • Third-party web search application developers can now utilize the Windows search box in the taskbar using the instructions provided by Microsoft and choose any web browser to show results from the web.
  • Microsoft will no longer sign-in users to Edge, Bing, and Microsoft Start services during the initial Windows setup experience.
  • Data collected about the functioning of non-Microsoft apps, primarily bug detection and its effects on the OS, from Windows PCs will not be used for competitive purposes.
  • Microsoft, from now on, will need explicit user consent before combining data from the OS and other sources. It will also deliver new consent screens where required.
  • UmeU@lemmy.world
    link
    fedilink
    English
    arrow-up
    14
    arrow-down
    1
    ·
    9 months ago

    One drive is the one that really ruffles my feathers.

    It turns itself back on randomly, which wouldn’t be too much of a problem except for that it fucking remaps the desktop… a file that was previously located at C:\user\desktop\ is now at C:\user\One Drive\desktop…

    Note the space in the path, they didn’t even have the decency to use an underscore… \one_drive\… even though it’s one of their own rules in powershell scripting.

    For those of us using powershell to automate stuff this remapping is a nightmare and should be illegal.

    Too bad I am in the US and will just have to continue to get support calls from time to time when a users desktop gets remapped behind the scenes.

    Maybe there is a way using powershell and windows scheduled tasks to check to see if one drive turned itself back on, then auto turn it off and remap the desktop back to normal.

    The absurdity of having windows check to see if windows screwed itself up, then if so have it fix itself is just laughable.

    • DAMunzy@lemmy.dbzer0.com
      link
      fedilink
      English
      arrow-up
      1
      ·
      8 months ago

      That’s so weird. I was just praising M$ to myself because I noticed that they are using \OneDrive\ and \Documents\ now and no spaces to be found.

    • kylian0087@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      8 months ago

      You know you can completely disable onedrive using GPOs?. I have done so on a DC i have but it shut also be possible using local GPOs.

    • Simon@lemmy.dbzer0.com
      link
      fedilink
      English
      arrow-up
      1
      ·
      9 months ago

      Why aren’t you string quoting all of your paths anyway? I’m confused because the vast majority of paths wouldn’t work the way you’re suggesting.

      • UmeU@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        8 months ago

        Even something as simple as:

        move-item “C:\Users\computername\Desktop\afiletomove.csv” (“C:\Users\computername\Desktop\destinationFolder\newFileName (0:MMddyyyy).csv” -f (get-date))

        Stops working as intended when your desktop no longer resides at that path.

        Also, I have the same functions running on multiple machines with different names so I have to dynamically resolve the path and piece it together using strings.

        • Simon@lemmy.dbzer0.com
          link
          fedilink
          English
          arrow-up
          1
          ·
          8 months ago

          Okay, so if your source path changes, your script stops working? Who knew. Try ([Environment]::GetFolderPath(“Desktop”))

          • UmeU@lemmy.world
            link
            fedilink
            English
            arrow-up
            1
            ·
            edit-2
            8 months ago

            I am using that already, but if I recall, it’s the space in the path ‘\one drive\’ that makes that not work correctly.

            Edit: I am actually using $Env:UserName

            • Simon@lemmy.dbzer0.com
              link
              fedilink
              English
              arrow-up
              1
              ·
              edit-2
              8 months ago

              Yeah the deeper path might help.

              Basically the thing to remember about powershell that separates it from other scripts is you want to pipe pipe pipe your data as far as possible so it stays an object, and then output a string at the very end - there’s no tons of awk sed string manipulation like in bash, partly because of what you pointed out with how terminal input is interpreted.

              • UmeU@lemmy.world
                link
                fedilink
                English
                arrow-up
                1
                ·
                8 months ago

                It’s only happened twice, after updates, that windows turned one drive back on and remapped my desktops. In those cases I have just turned it back off and remapped back to normal. Then env:username works again and I think the only difference is the space in the path with one drive, though it could be something else breaking when the desktop gets remapped.

                I’m probably using powershell all wrong anyways because I am an amateur.

                I use it to grab a file from an sftp by calling on winSCP, then convert from csv to xlsx using the excel module, then run a bunch of VBA to reformat the file, then save the xlsx with a date stamp. I use task scheduler to run it daily and I have it on like 10 machines.

                Works great when one drive doesn’t mess with my desktop path.