5 Replies Latest reply on Oct 10, 2014 1:53 PM by John Siegel

    Mobileprint and limiting email accounts

    John Siegel Guide

      I've seen a bit of chatter about character limitations (max 255) with Mobileprint from the perspective of not providing enough character space for email account adds. What about going in the other direction. Anyone restricting the number of accounts? If so, how are you going about it? If you are using the email registration process, did you get any push back from IT security, if so, how did you get around their concerns?

       

      CU wants to try and limit the number of accounts to two per user. Allowing email accounts without governance is becoming a support nightmare. CU uses a program called ID Manager that allows students, faculty and staff to change their default email account to any of approximately 75 different domain names, i.e. @engineering.colorado.edu, @spot.colorado.edu, etc.That's not including the potential use of outside accounts, i.e. @gmail.com, etc. We get help desk calls with users complaining that Mobileprint isn't working when in fact the problem is they are sending from an email address that is not registered with Mobileprint.

       

      Since we can't use the email registration capability (due to the concerns of OIT security), in our system, using a script, the Pharos DB captures the user data from the print release station when the users card is swiped for the first time. The LDAP is queried and the info placed in a user account. ID Manager is synced with the LDAP. That means that whatever email account the user has set in ID Manager as the default is the one that gets  "registered" in the Pharos DB. So they have to know which account was the default when they swiped their card the first time and send from that account to Mobileprint. If we could restrict it to one of two accounts, they would know ahead of time which to send from instead of trying to remember (don't forget, pot is legal in CO, I wonder if the University of Washington has similar problems ) which default email they registered.

       

      As an aside, does anyone know how to get a twinkie wrapper out of a Multifunction device?  

       

      Regards,

       

                    John

        • Re: Mobileprint and limiting email accounts
          Chris Axtell Navigator

          Hi John,

           

          We're in the preliminary stages of setting up our MobilePrint environment and our strategy for supporting email registration is simple. We're disabling the ability for individuals to register an email address with Pharos, and are only supporting email addresses that end in one of several possible domains that are associated with the university. Accordingly we are pre-populating the Pharos User records via a PowerShell script that formats the necessary data into a CSV file for the Pharos batch user load tool.

           

          Our identity management tool allows an individual to register up to 4 vanity email aliases, of course an administrator may have added additional aliases in the background in order to ensure proper routing of legacy username formats.

           

          We use AD as our user authentication source so the PowerShell script looks at both the "mail" and "proxyaddresses" to determine the primary email address. There is logic to ensure that the email address is associated with one of our domains, if it doesn't then we set the value to be the most generic university email format possible which based on our mail routing rules we know should always work. After this is set, we then continue to process the proxyaddresses attribute for any email alias that also ends in one of the university domain names. In our case we don't care how many aliases are registered with Pharos as long as we don't exceed the 255 character limit. So as we continue to evaluate each alias we test the string length of both the "UserEmailAddress" variable and if the current found alias address are short enough to be combined. If not then we don't add the alias address to the list.

           

          The end result should allow patrons to use any of the university email address that is registered with the account. If they use our identity management tool to edit their aliases then this information will be updated during the next nightly provisioning process. In our early testing we're seeing accounts registering up to 7 email addresses using about 159 characters. We've made the business decision at this point to not support non-university email domains such as @gmail.com, @outlook.com, etc. since we have no way to verify the account belongs to someone affiliated with the university.

           

          You're on your own with the twinkie wrapper...

           

          Chris

            • Re: Mobileprint and limiting email accounts
              John Siegel Guide

              Hi Chris,

               

                            That sounds right to me, unfortunately CU doesn't have a single AD or LDAP that contains all the user data. To further complicate matters multiple groups on campus that are outside the OIT span of control have their own servers that do not propagate to the OIT servers, so there is no consistent way to update the uploaded info, assuming I can get an all encompassing list to start with. We are running a script that allows the system to capture the associated user login and email account via the Omega print release stations, to populate the Pharos DB. Unfortunately as I mentioned, presently there is no good way to support this model because students can and do change what the "captured" email was in Pharos when they originally swiped their card. One possibility would be to add a second email account to the LDAP that is matched in the ID Manager custom fields and leave the two email fields static and change the script to capture both. That would mean we would know what the "assigned" Mobileprint emails are and could point users towards those when they call in saying they are getting a "you need to register your email" message.  Rich Post"s idea of using omegas and allowing users to update manually may be the only other possibility to get this to work the way the university wants.

               

               

              Regards,

               

                            John

              • Re: Mobileprint and limiting email accounts
                John Siegel Guide

                Update: Not sure if this would apply to other institutions, but we came up with another idea.

                 

                                       In our environment users have two known emails, but only one exists in the queried LDAP. The LDAP stored email is always first.last@Colorado.edu. There is a second address assigned (using the Identikey user logon as the first part)which is first two letters first name first two letters last name random 4 numbers@colorado.edu (example josi5911@colorado.edu) for all students. We are looking at the possibility of creating a script that would automatically add the second address to all student accounts. We capture a user logon which matches the second address (ex; my identikey (user logon) as a student would be josi5911.) so we would need to append the captured address, ex: john.siegel@Colorado.edu so that it adds the second address, josi5911@colorado.edu, separated by a comma. That would give us the ability to instruct students to ensure that either first.last@Colorado.edu, or first two letters first name first two letters last name random 4 numbers (their Identikey)@colorado.edu is set in ID Manager as the default email in order to print via Mobileprint. It still doesn't solve the problem of additional emails for faculty and staff, but the students are the vast majority currently using Mobileprint.

                 

                 

                 

                ~John

              • Re: Mobileprint and limiting email accounts
                Rachel Deaton Navigator

                Very interesting feedback, gentlemen, thank you so much for sharing.

                 

                Also, I will get in touch with support about twinkie-wrapper troubleshooting