I'm here going to deploy (Intune) in our company however, the previous users use to Mass360 as the MDM. Is there any way we can detect when users will receive emails outside of Microsoft Intune? We are planning to block them until they enroll in Intune.
Thank you all in advance.
I've tried researching on this topic, nothing pops up.
Related
We've written an application to replace a third party tool to download and print jobs through Google Cloud Print. For new customers this will work well. We create the printer in the cloud and download jobs. It works. Customers up and running with the third party tool are using a printer created with that tool. I thought I'd be able to access that printer's jobs by getting the user to go through oauth authentication to give our application the permission to manage the user's printers. However, having done this and all seeming to work when I fetch jobs from that printer the response is that there are no jobs. But there is a job. Is this behaviour to be expected. Is there any way around this? We'd just like to avoid our customers having to create new printers.
The question is a little unclear; feel free to edit your question and I'll edit this answer.
Being able to manage jobs is not the same as being able to download jobs. Each printer belongs to a user, and each has a robot account. Only those two accounts (I believe) can download the job ticket and payload.
After a job is marked as completed (through the /control API), the payload is deleted.
A third user account that can manage jobs is allowed to view information about the job, as well as cancel/delete the job, but can't (I believe) download the job payload.
I know I can use Google Apps Script to send an email from the account that is currently logged in. I'm wondering, is it possible for a "master" Script on one account to push a trigger of some kind out to a series of other Google Accounts, telling them to run their scripts?
Essentially I need to send a bunch of emails from various different accounts, and the user who runs the script won't be able to log into all of them. I'm looking for a way to make all these accounts listen for a central signal to run their scripts.
Does this make sense? Any thoughts?
Thank you,
Pacific 231
The short answer is yes...
You will have to write one script for each account that will run as a service (deployed as webApp with its own url) and your master script will have to call each of them using an urlFetch with some parameters added to the url telling them what email to send. You'll have to add some security feature to these calls.
Every webApp service will run as the user who wrote the script and will be accessible to anyone (if in a Google Apps account you will be able to restrict the use to members of the Google Apps community).
This is not too hard to do but will require some work though...
We'll be glad to help you if you meet specific issues.
I'd like to deploy a Office 365/Exchange Online management portal in the WAWS(Windows Azure WebSite) which could create new user/group/mailbox or change some property of specific user, etc. Is it possible to deploy this kind of web application in the WAWS environment? Should I call PowerShell and Office365 cmdlet in the ASP.NET environment? Or there are any better way to do this?
As the #Matt alludes to in his comment, there is already a web-based management portal for both of these. However, since you ask this question, I'm going to assume that you want additional functionality/customization.
The short answer is yes, you can.
User accounts in Office 365 are, behind the scenes, accounts in Azure Active Directory. So, for creating users, contacts, security groups and adding licenses, you will need to use the Azure Active Directory Graph API:
Getting Started With Windows Azure Active Directory Graph
For managing Exchange Online, you will probably want to use the Exchange Web Services Managed API 2.0. You'll probably only need this if you need to create distribution groups or manage individual users' contact folders (mailboxes for users get created when you assign an Exchange license from Azure Active Directory).
Get started with EWS Managed API client applications
Update: the Office 365 APIs were recently announced, and are now in Preview. They are a RESTful API, which can be used to manage (for now), mail, contacts and calendar items. Depending on your use case, this may be easier to deal with than the EWS Managed API 2.0.
Using the Mail, Calendar, and Contact REST APIs to work with emails, calendar items, and contacts
I am doing some dev work for a client. She has a Dev License should would like to put the app under but since she is non-technical it has been frustrating since she has to be the one to submit the final app.
Is there a way for a Dev License to have multiple Admins? I have it configured so I am a developer but as such I cannot do the Distribution License. Only she can do that. Is there a fix?
If you have a good relationship to your client, you might want to ask her for her login details so you can do it yourself.
There is one other possibility though: For a similar problem I was given the advice to build & archive my app and send the archive to the client. He could then resign the app using his certs, which would eliminate the need for him to do all the building stuff, not to mention it will spare you to surrender your source code. However, this will not eliminate the need for your client to enter all the meta information and so forth while uploading the app.
For the necessary steps to resign an app, see this answer.
To answer your original question: Each developer account has exactly one Team Agent. So you need some kind of workaround anyway.
There is only one administrative or Team leader per developer account. So you really need to plan on the policy for sharing use of that account from the beginning, if the required activities of the agent need to be split up among multiple parties, if you can't have one party capable of doing everything.
A shared account can be created from the beginning (either by the owner or the developer). I recommend an ADC account be created just for this purpose, instead of just using the owner's personal account and email address ( e.g. instead of mary.smith#sample.com, create and use iosdeveloper#sample.com for enrolling as an iOS developer. )
Account credentials can be "loaned" (perhaps with password changes after use).
You can be given remote access (VNC/RDP) into the owners PC or Mac (or more secure yet, a VM session) as or after they log in.
You can talk the owner though the process over the phone (or video chat, etc.).
Or, the owner can learn how to get certificates, and build or resign and submit apps themselves, perhaps using a comprehensive script.
I am evaluating cloud e-mail solutions based upon:
Google Apps for Education
Microsoft Live#edu
I work for a University and we currently have an institutional portal (based on uPortal).
We currently have our local IMAP server and webmail client fully integrated with the portal. We would like to replicate the current portal e-mail experience with the new e-mail services. At present users can see a snapshot of their inbox in the portal and click through into the appropriate place in the webmail client.
We expect that we need to solve similar problems when integrating with the cloud based e-mail solutions.
We need to solve the single sign-on (SSO) problem.
We need to be able to access the inbox messages on the users behalf. (e.g. proxy authentication)
Does anybody have an experience or advice on this?
Many thanks,
Mark
Not sure what programming language you can use, however you can download the source code for some MOSS web parts for live#edu to give you an idea how to code them, they use SSO.
If anybody else happens upon this page they might also be interested the answers I recieved via the Jasig uPortal Mailing List answers