To find Specific GPO Settings are being applied, and which GPO is affecting which setting, you can generate an html report, there are two ways of doing this. You can either run the report on the affected machine, or if you do not have access, you can generate the same report on a domain controller (or any machine that has the group Policy Management console installed).
Solution: Find Specific GPO Settings (Locally)
On the machine in question run the following command (remember to be logged in with the credentials of an affected user!)
It will take a little while for the report to be generated but it ‘should’ open in you default browser, like so.
From here you can see a list of all the applied GPOs, and drill down into each setting, and see the ‘Wining GPO‘ that applied that setting.
Solution: Find Specific GPO Settings (Centrally)
Most people are unaware that you can do the same from any machine that’s running the Group Policy Management administrative tool, it has a section called group policy modelling. the reason this exists is to ‘try out’ the effect of changing groups, OUs and WMI filters to see how that affects the application of GPOs to both users and computers however, if you just plus in the computer name and the users name and accept all the defaults it will give you the SAME report you generated above.
From Administrative tools > Group policy management > Group Policy modelling > Group Policy modelling wizard > Next > Next (unless you want to change the DC queried).
Select the user and computer in question > Next > Next > Next.
Next > Next > Next.
Next > Next > Finish.
The report will be rendered on screen, with the same information as if you had run gpresult manually on the client.
Related Articles, References, Credits, or External Links
Seen on a Microsoft Hyper-V failover cluster (Server 2019);
Network Interfaces {Node-Name} {Interface-Name} and {Node-Name} {Interface-Name} are on the same cluster network, yet address {IP-Address} is not reachable from {IP-Address} using UDP port 3433
Solution
I’ve seen this error before, and usually you just need to disable the firewall or open UDP port 3433 and then re-validate the cluster (job done). However, in my case the following was true;
All IP addresses could ‘ping’ the IP addresses that it was telling me it could not communicate with.
All local firewalls were turned off on the domain profile.
No AV was running, or third party firewalls were installed.
There seemed to be no reason for this, I disabled and re-enabled the ‘Live migration’ NIC and 50% of the links ‘went green’ but then the Live Migration link said ‘partitioned‘ 🙁
In the end, (even though the cluster was in a failed state) I moved all my VMs onto one Host, then ran Windows update, and bounced the server, then repeated the process on the other host and the problem went away. I don’t know it it was a bug/update/driver problem, but fingers crossed it’s been OK since.
Related Articles, References, Credits, or External Links
1. Make sure the user you will be performing the migration as, is in the right security groups, (Organizational Management and Recipient Management).
2. On the Legacy Exchange server download the PF-Migration-Scripts-v2 Then extract them to the servers C: drive.
3. Launch the Exchange Management Shell > Change to the script directory > Then create a folder name to folder size mapping file by running the Export-PublicFolderStatistics.ps1 script, supply the name of the file you want to create. (Here I use PublicFoldersStats.csv). Then supply the name of the server, (the legacy one, with the source public folders on it).
[box]
cd c:\Scripts
./Export-PublicFolderStatistics.ps1 PublicFoldersStats.csvMail-Server
[/box]
4. Create a Public Folder to Mailbox mapping file, by running the PublicFolderToMailboxMapGenerator.ps1 script, supply it with the maximum mailbox size (in bytes) Note: The Maximum size is 25GB. You will also need to supply the import file you created in step 3 (PublicFoldersStats.csv). Finally supply the name of the output file you wish to generate i.e. Folder2Mailbox.csv.
[box]
./PublicFolderToMailboxMapGenerator.ps1
[/box]
5. Open the last CSV file you created (Folder2Mailbox.csv) and take note of the TargetMailbox name. By default the first one is called Mailbox1, I’m changing it to Public-Folder-Mailbox and saving the change. Note: You may get more than one! If so take note of them all, or rename them accordingly.
6. Now copy the ‘Scripts’ Directory from your legacy 2010 Exchange server, to the new 2013 / 2016 Server.
7. Whilst still on the new Exchange 2013 / 2016 Server, you need to open a command shell, navigate to the scripts directory and then run the Create-PublicFolderMailboxesForMigration.ps1 script. Reply ‘A’ to run all the scripts, then supply the name of the mapping csv you created above, (Folder2Mailbox.csv). Supply the estimated concurrent users to this mailbox, and enter ‘Y’ to proceed. Now the public folder mailbox will be created.
(Note: Public folders are now in a Mailbox, NOT their own Mailbox database, as in older versions of Exchange).
[box]
cd c:\Scripts
./Create-PublicFolderMailboxesForMigration.ps1
[/box]
8. Next we need to create a ‘batch task’ much the same as when we migrate multiple mailboxes. This first command creates the task, and the second one sets it running. (Change the values in red to match your own).
Update: 05/08/16: Make sure you have a ‘mailbox database’ mounted on the source Exchange server before proceeding, or you may see the following problem.
It might say Queued for quite a while, don’t worry!
Check Public Folder Migration Progress Option 2 From EAC
Open the Exchange Admin Center website and logon. Navigate to recipients > Migration > View Details
10. If you were looking at the progress you will see its stops just before 100%, this is because you need to “Lock” the source public folder and let the migration complete. WARNING this will involve downtime, so warn your users, or do this next step out of hours.
To MAKE SURE you are ready, check either the progress report like so;
Or, re-run the progress command above and look for 95% completion and ‘Automatically suspending job’
DOWNTIME FROM THIS POINT ONWARDS
11. Go to the legacy Exchange 2010 server and ‘lock’ the source public folders for migration, and restart the service.
12. Now access to the legacy Public Folder Database is shut down, but before replication to the new Public Folder Mailbox can be completed you need to return to the new Exchange 2013 / 2016 server and run the following commands;
This can take a little time, I would wait least a couple of hours before proceeding (depending on your network topology, if you have a slow network or the Exchange 2010 server is on another network segment it may take longer).
Now to check the migration worked with a test user, and (provide everything is OK, unlock the Public Folders.
Log on as that user, (Outlook 2010 SP3 or Later.) Make sure the public folders are correct, you can expand them, the permissions are correct and you can create and delete entries.
It’s All Gone Wrong!
Don’t panic! You can remove the migration request with the following command;
Note: As per feedback (from Tobias Gebler) Test mail flow to your public folders, you may need to manually “Mail Enable” them before they function properly, In some cases you need to disable then re-enable them before they work properly.
14. Remember in Outlook Web App 2013 / 2016, public folders are not visible until you add them!
Note: If, (post Migration to Exchange 2016). Your users cannot access the public folders, see the following article.
Before SP1 you would have to install a copy of Outlook on the Exchange server and use a PowerShell command that looks like this (once you had granted Import/Export rights);
[box]
BEFORE Exchange 2010 SP1
Get-Mailbox | Import-Mailbox –PSTFolderPath C:Folder_Containing_PST_Files
[/box]
However try that after SP1 and you will get an error message, saying that Import-Mailbox is not a commandlet. That’s because now you no longer use this command you use “New-MailboxImportRequest”, and you also no longer need Outlook installing on the server.
“This mailbox exceeded the maximum number of large items that were specified for this request. (Fatal error TooManyLargeItemsPermanentException has occurred.)”
To fix that error you can use the ‘-LargeItemLimit 200 -AcceptLargeDataLoss’ flags (which sounds alarming, but I have not seen it break anything in the last ten years).
Importing PST Files From the Exchange Admin Center
You can import PST files directly in the management GUI > Recipients > Mailboxes > Select the target mailbox > {Ellipses} > Import PST.
Enter the path to the .PST file > Next.
Select the target mailbox > Next.
Optional: Select a user to be emailed an export report.
Note: To view progress and troubleshoot failures, you will have to revert to PowerShell.
How To BULK Import .PST Files
Note: To BULK Import successfully, the .PST file MUST have the same name as the alias of the target mailbox.
Commands Required
1. Once you have created a “Universal Security Group” in this example called “Mailbox_Import” then assign the mailbox import/export roles with the following command;
FailureType : TooManyBadItemsPermanentException Message : Error: This mailbox exceeded the maximum number of corrupted items that were specified for this move request.
This happens when it sees items in the mailbox it does not like, or considers corrupt. To get round this problem, import the .pst file on its own with the following command;
