I can’t really take the credit for this, I was at a client’s site a few weeks ago, and they were doing this. I thought ‘That’s cool, I’ll have a play with that when I get the chance”.
Essentially, you update the description of the Computer object(s) in AD so that they list;
The last user who logged on.
What time they logged on.
What AD ‘Site’ the machine is in.
Model of the PC/Laptop.
Serial Number of the machine.
Operating System.
32 or 64 bit.
I tested it in VMware so my machine type and serial number are a little misleading but this is what it looks like.
Now I can think of loads of situations when that information would be very helpful?
Solution : Last User
So how do you do it? Well to make a change to a computer’s ‘Description’ filed in AD, requires some rights, locate the OU (or OUs) that contain your computers/servers and open the advanced properties on their security tab.
You can either ‘Add’ (as shown), or select the existing ‘Authenticated Users’ object from the list.
Change the ‘Applies to’ section to ‘Descendant Computer Objects’.
Scroll down and tick, ‘Write Description’
Isn’t that dangerous? Well not really, it gives users the right to change a computer objects description field, they would need to have the technical ability to do so. And if they did it would get overwritten the next time a user logged onto that machine anyway.
Download the ComputerDescriptionLogonStamp.zip file, and extract the two files you find inside it, into your domain netlogon share (\\{your-domain-name}\netlogon). Edit the domain name in the ComputerDescriptionLogonStamp.bat file so it matches YOUR domain name not mine!
Now create a new Group Policy Object, linked to your USERS.
Edit the policy, and navigate to;
[box]User Configuration > Windows Settings > Scripts > Logon[/box]
Add in the UNC path to the ComputerDescriptionLogonStamp.bat file (Note: Make sure you use a UNC path, to your Netlogon folder, and you do NOT browse locally to the file, if the path looks like; C:\windows\sysvol\pnl.con\sysvol\ComputerDescriptionLogonStamp.batIT WON’T WORK.)
Close the Group policy editor, then either wait, or force a group policy update.
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.
