Sending Mass Emails in C#

I like many developers am tasked with creating batch emails to send to a large population of users.  And for this I am not talking about spam, I am referring to sending emails to a large poplulation within an organization such as annual notification reminders or custom links to some application.  I have tried sending these emails synchroniously and if you are sending a few hundred that isn't a problem, but when I started sending several thousand, I was noticing a bottleneck with my SMTP server and waiting for the callback showing the SMTP server receved the message.  

So moving forward from that thought the best option for sending mass emails greater than a few hundred is using threading and asynchronious sending.  I have tried this a few different ways in the past with event listeners and different techniques, but moving to the async and await world of modern .Net I thought I would re-write it with some more modern tooling.  Since this took me a little trial and error I thought it would be a good thing to post for my fellow developers out there. 

From a performance standpoint using the same SMTP server I was getting about three emails per second with standard synchronous methods and when I went to the attached code, I went up to about 18 (running locally over VPN to our corporate offices) and I will expect to see an even bigger jump on a VM in the datacenter.  Overall there isn't much impact to performance on the machine with minimal CPU and RAM overhead.  

Anyway, click here to get to my code.  

Two things I want to point out:

  1. I know I have a weird try / catch in there.  That is because the mail server was choking with that many emails going through at one time and I was getting random errors.  Retrying one time usually fixed it.
  2. I know there are async methods with the SMTP client, but when you use that it still only allows one email to be processed at a time by the general SMTP client thus making it an async method but not async in the since that I wanted which was mass emails with threading.

o365 Groups, My Hatred of it

I hate PowerShell, I hate o365 (more specifically o365 Groups / Outlook Groups), and I hate SharePoint in the Office 365 Tenant. 

I know that is a strong way to start off a statement on managing o365 Groups but after banging my head against the wall for too long around o365 Groups I can’t think of a more appropriate statement regarding my feelings for Microsoft’s new product line.  So let me break down my frustration and give a few insights.

I am going to start with my hatred of SharePoint.  First off, the platform is a pig and it is a bloated pig, but I am not going to get into that right now.  With Microsoft’s new direction for SharePoint in building other products on top of it such as o365 Groups or Planner, Microsoft is stepping in the world of SharePoint and making a muck of the SharePoint environment with other products that trample over the storage and URL-space of the SharePoint tenant.  So when you create an o365 Group or a Planner plan, then you have created a SharePoint site collection in the tenant that you don’t see in the dashboard or have direct control over the quota (without PowerShell). 

Moving into my hatred of o365 Groups.  Here is a product that Microsoft is building as a collaborative communication tool (what about Yammer) and they are encouraging users to create their own groups, but they have little governance on how the groups are created (and that is just coming in now).  One exciting thing about groups is that the users can create whatever they want… and guess what, it shows up in the GAL.  A user could effectively create a group saying “Union Formation Group” and what could the company do to stop it, they could create a lot of legal problems in the company instantly and there is no way to really stop it short of turning off Groups.  Keep in mind that these Groups use quota from SharePoint too.  Here is just another though on Groups, the name.  We have AD Groups, Azure Groups, o365 Groups, just group Groups, and where will this end.  Let’s stop using generic names for products (Word?) which causes so much confusion when using the Google to try to return information (“the Google” was not a typo, it is a being now).

Lastly, I am going to complain about PowerShell or more specifically the implementation of PowerShell and the documentation for the o365 Groups.  Microsoft’s documentation is scattered and not clear on top of the fact that when you search for “Office 365 Group” or “o365 Group” you get everything from groups about o365 to permission groups in SharePoint (back to naming).  Even when you find the documentation that shows things like optional parameters for the PowerShell it is very incomplete.  For example, many of the options that are available on “Set-UnifiedGroup” (did you notice that one?  All of a sudden an o365 Group is called a “Unified Group”) are available too on “New-UnifiedGroup” even though it doesn’t show up there in the documentation.  Here is another fun one, if you want to set the quota for the file storage, it is a SharePoint PowerShell command and does not involve the “Unified Group.”  My favorite of all, I was trying to interact with the “Description” field for the o365 Group but that is the “Notes” field in PowerShell, what the hell?  Why do you even use named properties when you change the meaning of the names or the names in the UI. 

Well, there was my rant.  I doubt there will be anything helpful, but if you want the complete current list of PowerShell parameters I have it below.  Please look back in a few weeks for some examples on connecting to PowerShell through C# to create a new Unified Group or whatever the hell Microsoft changes the name to next.

 

  • New-UnifiedGroup
    • [-AccessType <Public | Private>]
    • [-Alias <String>]
    • [-AutoSubscribeNewMembers <SwitchParameter>]
    • [-Confirm [<SwitchParameter>]]
    • [-Database <DatabaseIdParameter>]
    • [-DisplayName <String>]
    • [-DomainController <Fqdn>]
    • [-EmailAddresses <ProxyAddressCollection>]
    • [-ExecutingUser <RecipientIdParameter>]
    • [-ExternalDirectoryObjectId <String>]
    • [-FromSyncClient <SwitchParameter>]
    • [-Language <CultureInfo>]
    • [-ManagedBy <RecipientIdParameter[]>]
    • [-Members <RecipientIdParameter[]>]
    • [-Name <String>]
    • [-Notes <String>]
    • [-Organization <OrganizationIdParameter>]
    • [-OrganizationalUnit <OrganizationalUnitIdParameter>]
    • [-OverrideRecipientQuotas <SwitchParameter>]
    • [-PrimarySmtpAddress <SmtpAddress>]
    • [-RecipientIdType <Unknown | ExternalId | Smtp | LegacyDn>]
    • [-RequireSenderAuthenticationEnabled <$true | $false>]
    • [-SharePointResources <MultiValuedProperty>]
    • [-SuppressWarmupMessage <SwitchParameter>]
    • [-ValidationOrganization <String>]
    • [-WhatIf [<SwitchParameter>]]
    • [<CommonParameters>]

The IKEA Dignitet

So my wife purchased something to hang some of the kids artwork on the walls and while the product looks innocuous enough it is really a nightmare.  The product I am writing about is the IKEA Dignitet Curtain Wire (http://www.ikea.com/us/en/catalog/products/60075295/).  I am sure that many people have seen this product on Pinterest but this is not a product I would recommend (at least if you have drywall walls).  I installed it as directed by the very short instruction manual but there was no mention about the proper wire tension or anything about proper anchors for the walls.  I chose to use wall anchors that are rated for fifty pounds each which according to that logic each pedestal should be rated to 150 lbs assuming the drywall would hold that much weight.  So upon installing the brackets which went fine, I began to tension the wire (not too tight from what I could tell) but my wall anchors began pulling from the drywall.  Due to the narrow base and simple points on how this mounts it appears that it becomes very easy to create a torsional force on the screws that were holding it on the wall thus increasing the amount of weight that was being applied to the screws.  So at this point I have six holes in my wall that technically are not strong enough to properly tension the wire.  I used ended up adding some tape around the screws to add additional size for the anchors and by not tensioning the wire very tight it appears to be holding.  

In summation, I would not recommend this product if you are going to mount it on drywall, it should be fine on a wood wall but other than that, this is not a good product.  

Yammer OAuth for data export

Anyone familiar with Yammer will know that many of the APIs are a bit lacking.  Also, all API connections will need an oAuth token that has access to the data in question.  So what do you do if you have a console application that needs to use Yammer Data Export API and drop the into a database or more to the point, how do you get the oAuth token?  I am not going to post the specifics on how to get the data and extract it but I will post some code on how to get the oAuth token.

To start there is some information you will need from Yammer which is only obtained after creating a Yammer app (https://developer.yammer.com/v1.0/docs/app-registration).  Your redirect URL for the included code needs to be http://localhost:80/Temporary_Listen_Addresses/  (if you get an error relating to access denied the port may be being used or it could be an issue with your privileges on the device).  *NOTE you do not need to publish your app for this functionality to work, so you can create the app then never finalize it.  Yammer's documentation https://developer.yammer.com/v1.0/docs/authentication-1 does not include the specifics on how to implement this on a console application and only includes the basic information.

The included code makse the assumptions that you will have the following app seetings in your App.config: "ClientID", "RedirectURL", "ClientSecret", and "oAuthToken" with all of these fields populated, with the exception of the "oAuthToken" field, from the information in your Yammer app settings.

I have included the complete class to perform the login here and to implement it you just need to call the constructor. 

  1. var yammerLogin = new YammerLogin.YammerAuthentication();
  2. string token = yammerLogin.oAuthToken;

The oAuthToken will be stored in the App.config and it will only re-auth if the token has failed to login. 

I hope this will help save a few hours of work for a few people out there.