Creating and Configuring Resource Mailboxes

  1. Create and Configure a Resource in Office 365 Admin

  2. Create and Configure a Resource in Exchange Online Admin

  3. Create a Resource with PowerShell

Create and Configure a Resource in Office 365 Admin

  1. Open your browser and navigate to http://portal.office.com
  2. Enter the account associated with your Office 365 tenant

2017-06-18_18-42-16

3. Navigate to the Admin Center by clicking the Waffle and Admin

image

4. Expand out Resources and click on Rooms & equipment

image

5. Click on + Add to add a new resource

6. Leave it set to type Room and then fill out the rest of the information: Name, Email, Capacity, Location and a Phone Number

7. Click Add at the bottom

8. You should now have a new resources added to your list.

9. Set the scheduling options by clicking Set scheduling options

10. This will show the room details you can configure around accepting requests for this resource.

11. You can either click save or Cancel.

You now have a new room added to your Office 365 tenant that is available for users to book when creating a meeting in Outlook.

Create and Configure a Resource in Exchange Online Admin

1. In the Office 365 Admin Center, expand out Admin Centers and click on Exchange

2. This will take you into the Exchange Online Admin Center. From here, click on resources under the recipients heading.

3. Here you can see the resources created earlier. To add another resource, click + and then click Equipment mailbox

4. This will popup a dialog box where you can enter the Equipment Name and E-mail address. Fill out the two text boxes and click Save. If you have multiple domains in your tenant, you can also select the FQDN for your mailbox.

5. You now have your new equipment resource created. Let’s edit this resource by double clicking on it.

6. Double click on the resource, it brings up all the additional information you saw when working with a resource in the Office 365 Admin Centre.

7. Click on booking delegates, this is where you can disable auto acceptance of requests and specify a delegate the must manually approve or deny resource requests.

8. Click on booking options next. Here is where we see those options that were available to us in the Office 365 Admin Center around configuring what is allowed or not allowed when booking a resource.

9. Uncheck Allow repeating meetings and click Save

10. Now, if any meeting requests come in that are recurring meetings to book this resource, they will be automatically denied.

Create a Resource with PowerShell

1. Log into a Windows machine with PowerShell installed

2. Open a PowerShell Console

3. Establish a new Exchange Online remote PowerShell session by running:

$UserCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange `
-ConnectionUri https://outlook.office365.com/powershell-liveid/ `
-Credential $UserCredential -Authentication Basic -AllowRedirection
Import-PSSession $Session 

4. Get what’s available. You can review existing resources by running the following PowerShell.

Get-Mailbox | Where {$_.ResourceType -eq "Room" -or $_.ResourceType -eq "Equipment"} 

5. Your window should like the one below:

6. Now, to create a new resource. Run

New-Mailbox -Name "PowerShell Room" -Room

This will create a new Room resource that will immediately show up when looking at the Office 365 Admin Centre or the Exchange Online Admin Centre. However, unlike the two mailboxes before, the Auto accept meeting requests will be Off.

7. Now that we have our new mailbox, run the following PowerShell again.

Get-Mailbox | Where {$_.ResourceType -eq "Room" -or $_.ResourceType -eq "Equipment"} 

You should see all three resource mailboxes now.  Let’s configure the one we just created.

8. First, let’s turn on Auto Accept with this PowerShell cmdlet

Set-CalendarProcessing -Identity "PowerShell Room" -AutomateProcessing AutoAccept 

9. Next, let’s configure a setting you can only set in PowerShell

Set-CalendarProcessing -EnforceSchedulingHorizon $false

If this is set to false, as long as a recurring meeting is scheduled to start on or before the window specified in the settings, the meeting request will be accepted rather than denied.

How the Execution Timeout is managed in ASP.NET

As you are probably aware, it is possible to specify the execution timeout of an ASP.NET request through the config file. All you need to do is to set the executionTimeout attribute on the httpRuntime element in either the web.config (for one ASP.NET application) or even the machine.config (to affect all ASP.NET applications):

<httpRuntime executionTimeout="200"/>

According to the online documentation the executionTimeout is a TimeSpan attribute that “specifies the maximum number of seconds that a request is allowed to execute before being automatically shut down by ASP.NET”. (BTW, it doesn’t work in debug mode)

The default value for this attribute has been set to 90 seconds in ASP.NET 1.x and was increased to 110 seconds in ASP.NET 2.0 or above.

Internally the timeout is managed by a timer (an instance of a System.Threading.Timer class) which is fired every 15 seconds.

Internally ASP.NET uses a Timer (an instance of System.Threading.Timer) to invoke the request cancelation process (As you are probably aware Thread.Abort() raises a ThreadAbortException in the thread on which it is invoked and the class responsible for this is System.Web.RequestTimeoutManager). This timer is fired once every 15 seconds, so if the executionTimeout is set to 3 seconds, in reality the request can timeout at any time between 3 seconds and 18 seconds.

When the timer is fired, a thread from the ThreadPool is used to check all the requests. The ones that have timed out are sent a ThreadAbortException by calling Abort on the thread executing the request.

So as per above, the executionTimeout only specifies the minimum duration that the request is guaranteed to be executed. The actual timeout can happen between executionTimeout and executionTimeout + 15 seconds.

Note: Keep in mind that ThreadAbortException can only be observed by managed code. So if you thread is calling some unmanaged functions, the thread will not be aborted, and therefore the timeout will not be enforced, until the execution returns to the managed world. That can be an arbitrary length of delay depending on what those unmanaged code does.

Web.config:

<system.web>

<httpRuntime executionTimeout="110"/> <!– default, Seconds–>

Sample Web Service Method (that you may use to test):

[WebMethod]

public string DoLongProcess()

{

//--- First Create the instance of Stopwatch Class

Stopwatch sw = new Stopwatch();

//--- Start The StopWatch ...From 000

sw.Start();

bool complete = false;

var t = new Thread(() =>

{

bool toggle = false;

while (!complete) toggle = !toggle;

Thread.MemoryBarrier();

});

t.Start();

Thread.Sleep(500000); //Milli-seconds (Web config - 36000000)

complete = true;

t.Join(); // Blocks indefinitely

//--- Stop the Timer

sw.Stop();

//--- Writing Execution Time

string executionTimeTaken = string.Format("Minutes :{0}\nSeconds :{1}\n Mili seconds :{2}", sw.Elapsed.Minutes, sw.Elapsed.Seconds, sw.Elapsed.TotalMilliseconds);

return "Completed long process in (" + executionTimeTaken + ")";

}