This article is about the most useful explination that I’ve seen about the different web parts that are provided (out of the box) by the different SharePoint license types.
http://www.sharepointconfig.com/2010/06/sharepoint-2010-web-parts-by-license-type/
Well I finally gave up on using Drupal to run my site and converted everything over to WordPress. So far WordPress has been a lot easier to work with, though I couldn’t find any tools to import my old Drupal data, but I did find some how-tos showing how to import a SQL dump into WordPress.
I still had to go back and edit almost every single post to fix formatting issues, which wasn’t so bad but was certainly tedious.
I also added some posts that were previously non-public after sanitizing some of the data in them. Unfortunately there are some scripts that I can’t share that I would like to due to them being specific to my current employer’s environment.
Also, due to restructuring a few months ago at work I no longer work daily with Exchange so I may not have as many tidbits to share, but I’m hoping to become comfortable enough with SharePoint (not 2010 unfortunately – I will miss PowerShell greatly) to begin sharing some useful bits of knowledge as I pick up that skill in the future.
Got auditors who want to review any mailboxes that have permissions granted for users other than the mailbox owner? If you do you’ll appreciate the usefulness of this oneliner, which will give you a list of all of the mailboxes that have special permissions assigned to them so that you don’t have to review every single mailbox on your system manually.
This command grabs all of the mailboxes that have non-inherited permissions for users other than the mailbox owner.
Want to know which users are assigned to a specific ActiveSync policy? It’s fairly straight forward, but unfortunately it’s not a single command.
You have to first retrieve the policy and assign it to a variable, then you can filter the Get-CASMailbox cmdlet based on that policy. This will give you a list of all of the mailboxes that are assigned to that policy that you can use for additional processing or reporting purposes.
As part of our migration from SCC to CCR in our Exchange 2007 environment, I had to write a script that evacuated all of the users off of a given mailbox server across a collection of other servers while taking into account the number of mailboxes per server/database and available disk space (projected by quota) . I can’t share the full script that I wrote, but I wanted to share a very useful method that I stumbled across to get the current count of mailboxes on the mailbox databases of a given server.
Normally the performance of the native Exchange Management Shell cmdlets is acceptable for daily administration, however for this process that we were using we discovered that enumerating 10,000 mailboxes to get a mailbox count per database wasn’t very efficient.
I basically took the method described over at sidefumbling and used it in the process and it saved me nearly 1 full minute per mailbox in the process which allowed us to perform the mailbox moves during a single tech window instead of having to split it across 2 different tech windows, subsequently allowing us to save a weeks worth of down time.
Work in a company long enough, and there will always be that user who does a reply-all to a large distribution list that spawns a huge reply-all storm. This normally leads to questions about how it was even possible for Bob from the warehouse to send a message to half the company, or the dozens of replies that landed in the CEO’s mailbox.
Fortunately, Exchange provides you with the ability to control who is allowed to use a distribution list. The problem is identifying what lists you may want to restrict. The good news is that using PowerShell, it’s fairly trivial to identify any Distribution Lists you have in your environment that have a large number of users in them. This is useful if you work in an environment where other departments have the ability to create Distribution Lists and you need to give them a list of the lists they need to restrict.
The basic logic is to look at all of the distribution lists in Exchange that are not restricted by either specific senders or other distribution lists, and report on the ones that have some arbitrary number of users. The following one-liner will give you a table of all of the distribution lists that have more than 500 members in them showing you the list name and the number of members in each list.
Sometimes you need to know specifically who a message was sent to and there may be no obvious way to determine that (such as it may have been sent to a distribution group, or the sender may have used BCC, or in my case that prompts this post – an external user). In these situations, the message tracking log in Exchange can be helpful but capturing the output in a format that you can send to your HR or Legal department may be a bit of a challenge, as the recipient field in the message tracking log is an array – and any type of collection object doesn’t export cleanly with the built-in cmdlets such as export-csv.
What you first need to to is establish what criteria will allow you to uniquely identify the message(s) you need to track for management. The best criteria is the message ID, but you can use a combination of criteria such as sender and message subject. These will become arguments to the Get-MessageTrackingLog Exchange Management Shell cmdlet.
In this case we are interested in who the message was actually delivered to, so you can further filter by the event ID of “deliver”.
Putting all that together, you end up with a Get-MessageTrackingLog command that will look something like this:
That’s simple enough, and it will return a stream of objects that match your filter criteria. But you need to give someone a report of who received this message. Unfortunately, it’s not as easy as piping the output to Export-CSV or Out-File. First you have to extract all of the recipients. The solution I used was a foreach-object loop on the results to create a CSV formatted result that I could then pipe to out-file. This allowed me to capture the recipients as a simple string successfully.
The ForEach-Object loop uses the -Begin code block to create the header records for the file, and the -process code block to actually capture the tracking log fields that we were interested in. The fields were placed in a sub-expression to allow for proper expansion of their values.
Take the previous two examples, combine them with a list of transport servers to retrieve logs from and feed the output to out-file, and you can construct a one-liner that will provide you with a simple report of who received a given email that you can share with your management.
Periodically you may wish to identify mailboxes that are still active in Exchange 2007 but which are not associated with active AD users. As you are aware, some mailboxes within Exchange require disabled accounts, so you generally want to exclude those mailboxes from such reports. Below is a script that I put together to produce a report of disabled user’s mailboxes.
I prefer not to use external utilities when possible, as it makes my scripts more portable in nature, which is why you’ll see the use of ADSI instead of the Quest cmdlets. This script does require the Exchange PSSnapIns, so you’ll want to execute this within the EMS.
- #This script is for getting a list of disabled users that still have mailboxes
- #Execute the script with the following command
- #.\DisabledUserMailboxes.ps1 -Output C:\DisabledUserMailboxes.csv
-
- param(
- [string]$Output = $(Throw "You need to specify the output file name using -output")
- )
-
- # Get a list of users with disabled accounts, that are mail enabled
- $domain = [ADSI]""
- $searcher = new-object System.DirectoryServices.DirectorySearcher($domain)
- $searcher.filter = "(&(userAccountControl:1.2.840.113556.1.4.803:=2)(homemdb=*))"
- [Void]$Searcher.PropertiesToLoad.Add("distinguishedname")
- $searcher.PageSize = 1000
- $searcher.SearchScope = "Subtree"
- $results = $searcher.findall()
-
- write-host "$($results.count) Disabled Users are mail enabled"
-
- # Create an empty array for storing the user data
- $users = @()
-
- #Enumerate through the disabled users and make sure they are user mailboxes, placing valid objects into the $users array
- foreach($result in $results) {
- $MailboxExists = $null
-
- #Verify the user has a mailbox that is a user mailbox, not a Room, Equipment, Shared, etc mailbox
- $MailboxExists = Get-Mailbox $($result.Properties.distinguishedname).tostring() | Where-Object {($_.recipienttypedetails -eq "UserMailbox")}
-
- # Make sure the result is neither an emtpy string nor a null value, if not add the current user to the list of disabled mailbox users
- if (($MailboxExists -ne "") -and ($MailboxExists -ne $null)){
- write-debug $($result.Properties.distinguishedname)
- $users += $($result.Properties.distinguishedname).tostring()
- }
-
- }
-
- # Export the list of disabled users that have Exchange mailboxes to a CSV file
- $users | select-object @{Name="DistinguishedName";Expression={$_}} | Export-Csv -Path $Output -Force -NoTypeInformation
One of the first challenges that we ran into was having to constantly type the password for the various transporter cmdlets that we placed into any of our automation for the conversion of mailboxes from Notes to Exchange. There are no examples that I could find for how to pass this information to a cmdlet such as Move-DominoMailbox. After some digging around I eventually stumbled upon the solution.
This allowed me to prompt for the credentials one time and store them in an encrypted file in a central location. The encrypted password information is user and workstation specific so it cannot be used by another user or even the same user on a different computer.
The following example will successfully allow the passing of a notes credential to the various Transporter Suite cmdlets without being prompted for the notes credentials:
To get and store the credential for the current user:
Example of use:
If you have service levels to maintain in your environment and a finite amount of disk space, there is a pretty good chance that you have mailbox quotas set to prevent users from over running your storage space.
Periodically you may be asked to report on the messages that were rejected for your environment because of full mailboxes. When Exchange rejects a message because a user’s mailbox is full, it generates an NDR (Non-Deliverable Report) with a status code of 5.2.2. You can search the Message Tracking Logs for this status code to determine who failed to receive messages due to their mailbox being full.
The following oneliner will produce a simple CSV report at %temp%\TooFullNDR.csv that includes the sender, recipient, message timestamp and recipient status (for further diagnosis if needed) for the most recent 24 hour period.
This is a sample of what the above will output if you didn’t capture it as a CSV.
Timestamp : 11/07/2008 3:32:18 PM Sender : david.sample@vendor.com Recipients : Michelle.baduser@company.com MessageSubject : Urgent: past due invoice RecipientStatus : 550 5.2.2 STOREDRV.Deliver: mailbox full. The following infor mation should help identify the cause: "MapiExceptionShutoffQ uotaExceeded:16.18969:AA000000, 17.27161:00000000D40000000000 00000F00000000000000, 255.23226:9D000000, 255.27962:FE000000, 255.17082:DD040000, 0.26937:94000000, 4.21921:DD040000, 255. 27962:FA000000, 255.1494:34000000, 255.26426:FE000000, 4.7588 :0F010480, 4.6564:0F010480, 0.22086:0F010480, 4.4740:05000780 , 4.6276:05000780, 4.23921:EC030000, 6.21970:0F01048040000C68 0F010480, 4.23921:EC030000, 6.21970:0F01048000806F670F010480, 4.24305:0F010480, 4.5721:DD040000, 4.6489:DD040000, 4.2199:D D040000, 4.17097:DD040000, 4.8620:DD040000, 255.1750:71040000 , 0.26849:0F010480, 255.21817:DD040000, 0.26297:0F010480, 4.1 6585:DD040000, 0.32441:0F010480, 4.1706:DD040000, 0.24761:000 00000, 4.20665:DD040000, 0.25785:00000000, 4.29881:DD040000".