Sigh - Well - there's the problem. - well likely anyway.

@brianlittlejohn said in Exchange Shell command not working: You also need to have export/import permissions granted to your account. They are not granted to anyone by default. This is what you need. First assign your user the Mailbox Export Role New-ManagementRoleAssignment -Role "Mailbox Import Export" -User "<user name or alias>" Then make sure the Exchange Subsystem has access to that shared folder and then run your export: MailboxExportRequest -Mailbox username -FilePath "\\server\PST FOlder\username.pst"

@MattSpeller said in Shadow Protect and Disk IOPS usage..: @scottalanmiller said in Shadow Protect and Disk IOPS usage..: @MattSpeller said in Shadow Protect and Disk IOPS usage..: @scottalanmiller said in Shadow Protect and Disk IOPS usage..: @DustinB3403 said in Shadow Protect and Disk IOPS usage..: The read usage on this system is insane for what it is normally doing. Even a tiny SW install we recommend some hefty resources and dedicated SSDs. You definitely just figured out the problem. Had you led with this we could have told you instantly what the issue was. Our rather beefy SW install runs on rust just fine. Not even a half decent rust array. Old junk. I'm surprised. Even when ours was tiny we gave it 100,000 IOPS and it remained slow. ¯\(ツ)/¯ There's only 3 of us in IT here. I suspect more concurrent users would kill it. We had probably ten or fifteen and loads of tickets. But that isn't that much of a jump, I wouldn't think.

In this case, it was a matter of the settings during the restore. Under GENERAL you had to select your source and destination as normal. Destination was changed so that it was the new History file. Under FILES you updated the DB and LOG files to reflect the new DB, otherwise you would over write the originals. This is where they borked it. They didn't mention FILES only going to OPTIONS, and there is where they mentioned updating the file names. The main discovery was that you need to uncheck LEAVE Source database in the restoring state. When I emailed them about removing the 'borked' databases I had created the called me back. I mentioned it to the fellow and we had a short discussion on the matter where he took notes and agreed that the directions were incorrect. When I got to the part about unchecking LEAVE Source database in the restoring state he mentioned that he uncheck Take tail-log backup before restore Hope this helps.

If it is a restart of the Hyper-V host, then check the services once it fails to respond like that.

Marked as answered.

@coliver said: repadmin /replicate DC1 DC2 dc=domain,dc=com So I have have limited success.. but success was made. I the user I created on the other end,.. is now on the local AD. I'll look at this more,.. but think it's otherwise solved.

@Dashrender said: @coliver said: @Dashrender said: Folders in that list that don't have the double folder within a folder icon are not OUs. As such GPO's don't apply to objects in them. learned this the hard way a long time ago. I guess I don't understand what this means. What icon are you talking about? Missed this. Ok thanks, that makes more sense.

@Dashrender What's weird though is I've gotten them to work here and there despite using msiexec. BUT then I changed some things around (added spaces....spaces make life hell but I wanted to see if I had to use " " around the path or not...utter failure, upon changing things back....I broke the installs) But yeah, I'm happy Now I just need to add what I've figured out to the other programs, which a few auto-activate lol, testing will have to be live. Ugh then I have to make more deployments for our Autodesk products, which actually isn't that bad..

@scottalanmiller said: Isn't this a client who was fired? Problem fixed! Yup... unfortuneatley the client refused to put in the hardware and required all updates to all machines be shut off, and requested all machines be rolled back from 10 that he hated....