Office 365 Scan to Email

Posted on by

Ok so this one had me stumped for a LONG time trying to figure out how to get scanners to authenticate to office 365 in the end i found out that the scanner i was using wasnt supported in this format so i found this work around hope it helps you!

You basically need to create an smtp relay on a local server / computer to forward your scans to then set the smtp relay up as below which will then do the authentication part for you.

 

SMTP relay settings for Office 365

To configure an SMTP relay in Office 365, you need the following:

  • A user who has an Exchange Online mailbox
  • The SMTP set to port 587
  • Transport Layer Security (TLS) encryption enabled
  • The mailbox server name

To obtain SMTP settings information, follow these steps:

  1. Sign in to Outlook Web App.
  2. Click Options, and then click See All Options.
  3. Click Account, click My Account, and then in the Account Information area, click Settings for POP, IMAP, and SMTP access.

    Note the SMTP settings information that is displayed on this page.

Configure Internet Information Services (IIS)

To configure Internet Information Services (IIS) so that your LOB programs can use the SMTP relay, follow these steps:

  1. Create a user who has an Exchange Online mailbox. To do this, use one of the following methods:
    • Create the user in Active Directory Domain Services, run directory synchronization, and then activate the user by using an Exchange Online license.

      Note The user must not have an on-premises mailbox.

    • Create the user by using the Office 365 portal or by using Microsoft Online Services PowerShell Module, and then assign the user an Exchange Online license.
  2. Configure the IIS SMTP relay server. To do this, follow these steps:
    1. Install IIS on an internal server. During the installation, select the option to install the SMTP components.
    2. In Internet Information Services (IIS) Manager, expand the Default SMTP Virtual Server, and then click Domains.
    3. Right-click Domains, click New, click Domain, and then click Remote.
    4. In the Name box, type *.com, and then click Finish.
  3. Double-click the domain that you just created.
  4. Click to select the Allow incoming mail to be relayed to this domain check box.
  5. In the Route domain area, click Forward all mail to smart host, and then in the box, type the mailbox server name.
  6. Click Outbound Security, and then configure the following settings:
    1. Click Basic Authentication.
    2. In the User name box, type the user name of the Office 365 mailbox user.
    3. In the Password box, type the password of the Office 365 mailbox user.
    4. Click to select the TLS encryption check box, and then click OK.
  7. Right-click the Default SMTP Virtual Server node, and then click Properties.
  8. On the Delivery tab, click Outbound Connections.
  9. In the TCP Port box, type 587, and then click OK.
  10. Click Outbound Security, and then configure the following settings:
    1. Click Basic Authentication.
    2. In the User name box, type the user name of the Office 365 mailbox user.
    3. In the Password box, type the password of the Office 365 mailbox user.
    4. Click to select the TLS encryption check box, and then click OK.
  11. On the Access tab, click Authentication, click to select the Anonymous access check box, and then click OK.
  12. On the Relay tab, select Only the list below, type the IP addresses of the client computers that will be sending the email messages, and then click OK.

Assigning “Send As” Permissions to a user

Posted on by

It was brought to my attention that following the steps listed in KB327000 (http://support.microsoft.com/?kbid=327000), which applies to Exchange 2000 and 2003, to assign a user “Send As” permission as another user did not appear to work.  I too tried to follow the steps and found that they did not work. I know this feature works, so I went looking around for other documentation on this and found KB281208 (http://support.microsoft.com/?kbid=281208) which applies to Exchange 5.5 and 2000.  Following the steps in KB281208 properly gave an user “Send As” permission as another user. But I found the steps listed in KB281208 were not complete either. The additional step that I performed was to remove all other permissions other than “Send As”.  Here are the modified steps for KB281208 that I performed (changes noted in blue):

1. Start Active Directory Users and Computers; click Start, point to Programs, point toAdministrative Tools, and then click Active Directory Users and Computers.

2. On the View menu, make sure that Advanced Features is selected.

3. Double-click the user that you want to grant send as rights for, and then click theSecurity tab.

4. Click Add, click the user that you want to give send as rights to, and then check send as under allow in the Permissions area.

4.5  Remove all other permissions granted by default so only the send as permission is granted.

5. Click OK to close the dialog box.

So after I verified that the steps for KB281208 worked, I was curious as to why the steps for KB327000 did not work.  What I found was that Step #7 of KB327000 applied to the permission to “User Objects” instead of “This Object Only”.  Here are the modified steps for KB327000 that I performed:

1. On an Exchange computer, click Start, point to Programs, point to Microsoft Exchange, and then click Active Directory Users and Computers.

2. On the View menu, click to select Advanced Features.

3. Expand Users, right-click the MailboxOwner object where you want to grant the permission, and then click Properties.

4. Click the Security tab, and then click Advanced.

5. In the Access Control Settings for MailboxOwner dialog box, click Add.

6. In the Select User, Computer, or Group dialog box, click the user account or the group that you want to grant “Send as” permissions to, and then click OK.

7. In the Permission Entry for MailboxOwner dialog box, click This Object Only in theApply onto list.

8. In the Permissions list, locate Send As, and then click to select the Allow check box.

9. Click OK three times to close the dialog boxes.

The KB articles were updated to include correct information. But, if you had problems with this in the past, this might be why!

How To View and Kill Processes On Remote Windows Computers

Posted on by

Windows provides several methods to view processes remotely on another computer. Terminal Server is one way or you can use the command line utility pslist from Microsoft Sysinternals site. While both options are good alternatives, Windows XP and Vista provides a built in utility for viewing and killing process on remote Computers using Tasklist and Taskkill commands.

Both tasklist.exe and taskkill,exe can be found in %SYSTEMROOT%\System32 (typically C:\Windows\System32) directory.

To view processes on a remote Computer in your home, you will need to know the username and password on the Computer you want to view the processes. Once you have the user account information, the syntax for using tasklist follows:

tasklist.exe /S SYSTEM /U USERNAME /P PASSWORD

(To view all tasklist options, type tasklist /? at the command prompt)

To execute, click on Start \ Run… and in the run window type cmd to open a command prompt. Then type the tasklist command, substituting SYSTEM for the remote computer you want to view processes, USERNAME and PASSWORD with an account/password on the remote Computer.

(NOTE: if you are in a Domain environment and have Administrator rights to the remote Computer, you will may not need to specify a Username and Password)

Fortigate and LDAP 4.0 MR3 Patch1

Posted on by

Hi Guys,

I have been setting up a lot of Fortigate’s recently and on my first few had issues with the settings for LDAP i found that it was tricky to remember the correct settings and also typing out the long LDAP Strings can be a bit tricky and cause typo’s.

  1. Logon to the fortigate and go to the Users -> Remote -> LDAP (Create New)
  2. Fill in a Name for the connector
  3. Fill in the IP Address of the server that has LDAP Installed
  4. Change the Common Name Identifier to: sAMAccountName
  5. Enter the Distinguished Name if your domain was domain.local the distinguished name would be: DC=domain,DC=local
  6. Make your Bind Type Regular
  7. In the User DN Box you must type the full path to the user e.g. if you user is domain.local/users/service accounts/fortigate you would need the following: CN=fortigate,OU=Service Accounts,OU=Users,OU=MyBusiness,DC=domain,DC=local
  8. type the password for your service account
This should be all that you require. one thing to keep an eye on is typo’s when doing the User DN this will stop you from being able to logon with an SSL-VPN or anything for that matter!
If you get an error in the logs for SSL-VPN saying no_matching_policy then you will have a typo somewhere.

Server 2003 Reinstall Terminal Services Licensing.

Posted on by

I Came across an issue today where i needed to reinstall terminal services licensing but when you do this licensing is lost and needs to be re-applied.

I managed to resolve this issue by copying the licensing db to a different folder and then re-installing terminal services and copying it back.

 

  1. stop Terminal Services Licensing service
  2. Copy c:\windows\system32\LServer\TLSLic.edb
  3. Paste the db to a different location
  4. Uninstall Terminal Services Licensing from add remove components
  5. Re-Install Terminal Services Licensing
  6. stop Terminal Services Licensing service
  7. copy the TLSLic.edb back to c:\windows\system32\LServer\ overwriting the new db that is in there
  8. start Terminal Services Licensing service

Now you will notice that TS Licensing is working and all of your licences still work.

 

NOTE: You CANNOT move this to another server it is registered to that Licensing server!!!

Block iGoogle with Fortigate

Posted on by

Ok so i had a customer that wanted to block iGoogle but allow google which turns out to be tricky as the only way to tell the difference is by the gadgets and the title bar.
i tried to do some research about iGoogle: every sites of iGoogle what I tested has the same title in html source code. Exactly: <title>iGoogle</title>

So you can use DLP sensor to detect this title in http request and block this sites. I have tested this on a FortiGate-60B with 4.2.3 version of firmware.


I tried to solve this problem over application control, web content filter and FortiGuard web filter but I didnt find solution here.

Warning: Cannot modify header information – headers already sent by…

Posted on by

Ok so today i was doing some PHP coding and get the dreaded header error caused me a bit of a headache as i needed to redirect some pages. After a bit of searching i managed to find an alternative to using:

PHP
1
header(location:&quot;index.php&quot;);

So to get rid of the error that this produces simply change it to any of the below:

PHP
1
2
3
4
5
6
7
ob_start();
//script
header(&quot;Location:file.php&quot;);
ob_end_flush();

OR

PHP
1
2
3
4
5
6
7
8
9
10
if ($success)
{
echo '&lt;META HTTP-EQUIV=&quot;Refresh&quot; Content=&quot;0; URL=success.php&quot;&gt;';
exit;
}
else
{
echo '&lt;META HTTP-EQUIV=&quot;Refresh&quot; Content=&quot;0; URL=retry.php&quot;&gt;';
exit;
}

OR

PHP
1
printf(&quot;&lt;script&gt;location.href='errorpage.html'&lt;/script&gt;&quot;);

i used the last option as i found this worked best compared to the others with my program however they may all work well for your application

Mapping a network drive in NT4 with logon credentials

Posted on by

Ok so today i have had a customer come to me saying that when they map a network drive in NT 4 the user details don’t get remembered when the pc is rebooted.

Here is a simple solution to the issue we have been having:

1
net use I: \\SERVERNAME\SHARENAME /User:DOMAIN\username password

run this at startup or as a logon script and the issue will be no more.

Send on Behalf and Send As

Posted on by

Send on Behalf and Send As are similar in fashion. Send on Behalf will allow a user to send as another user while showing the recipient that it was sent from a specific user on behalf of another user. What this means, is that the recipient is cognitive of who actually initiated the sending message, regardless of who it was sent on behalf of. This may not be what you are looking to accomplish. In many cases, you may want to send as another person and you do not want the recipient to be cognitive about who initiated the message. Of course, a possible downside to this, is that if the recipient replies, it may go to a user who did not initiate the sent message and might be confused depending on the circumstances. Send As can be useful in a scenario where you are sending as a mail-enabled distribution group. If someone replies, it will go to that distribution group which ultimately gets sent to every user who is a part of that distribution group. This article will explains how to use both methods.

Send on Behalf

There are three ways to configure Send on Behalf. The first method is by using Outlook Delegates which allows a user to grant another user to Send on Behalf of their mailbox. The second method is having an Exchange Administrator go into the Exchange Management Shell (EMS) and grant a specific user to Send on Behalf of another user. The third and final method is using the Exchange Management Console (EMC).

Outlook Delegates

There are major steps in order to use Outlook Delegates. The first is to select the user and add him as a delegate. You then must share your mailbox to that user.

  1. Go to Tools and choose Options
  2. Go to the Delegates Tab and click Add
  3. Select the user who wish to grant access to and click Add and then Ok

Note: There are more options you can choose from once you select OK after adding that user. Nothing in the next window is necessary to grant send on behalf.

  1. When back at the main Outlook window, in the Folder List, choose your mailbox at the root level. This will appear as Mailbox – Full Name
  2. Right-click and choose Change Sharing Permissions
  3. Click the Add button
  4. Select the user who wish to grant access to and click Add and then Ok
  5. In the permissions section, you must grant the user at minimum, Non-editing Author.

Exchange Management Shell (EMS)

This is a fairly simple process to complete. It consists of running only the following command and you are finished. The command is as follows:

Set-Mailbox UserMailbox -GrantSendOnBehalfTo UserWhoSends

Exchange Management Console (EMC)

  1. Go to Recipient Management and choose Mailbox
  2. Choose the mailbox and choose Properties in Action Pane
  3. Go to the Mail Flow Settings Tab and choose Delivery Options
  4. Click the Add button
  5. Select the user who wish to grant access to and click Add and then Ok

Send As

As of Exchange 2007 SP1, there are two ways to configure SendAs. The first method is having an Exchange Administrator go into the Exchange Management Shell (EMS) and grant a specific user to SendAs of another user. The second and final method (added in SP1) is using the Exchange Management Console (EMC).

Exchange Management Shell (EMS)

The first method is to grant a specific user the ability to SendAs as another user. It consists of running only the following command and you are finished. The command is as follows:

Add-ADPermission UserMailbox -ExtendedRights Send-As -user UserWhoSends

Exchange Management Console (EMC)

  1. Go to Recipient Management and choose Mailbox
  2. Choose the mailbox and choose Manage Send As Permissions in Action Pane
  3. Select the user who wish to grant access to and click Add and then Ok

Miscellaneous Information

No “From:” Button

In order for a user to Send on Behalf or Send As another user, their Outlook profile must be configured to show a From: button. By default, Outlook does not show the From: button. In order to configure a user’s Outlook profile to show the From: button:

Replies

If you are sending as another user, the recipient user might reply. By default, Outlook is configured to set the reply address to whoever is configured as the sending address. So if I am user A sending on behalf of user B, the reply address will be set to user B. If you are the user initiating the sending message, you can configure your Outlook profile to manually configure the reply address.

Conflicting Methods

If you are configuring Send on Behalf permissions on the Exchange Server, ensure that the user is not trying to use the Outlook delegates at the same time. Recently, at a client, I was given the task to configure Send As as well as Send on Behalf. As I was configuring Send As on the server, I found out that the client was attempting to use Outlook Delegates at the same time. Send As would not work. Once the user removed the user from Outlook Delegates and removed permissions for that user at the root level of your mailbox that appears as Mailbox – Full Name, Send As began to work. So keep in mind, if you are configuring Send As or Send on Behalf, use only one method for a specific user.

SendAs Disappearing

If you are in a Protected Group, something in Active Directory called SDProp will come by every hour and remove SendAs permissions on users in these protected groups.  What security rights are configured on these security accounts are determined based on what security rights are assigned on the adminSDHolder object which exists in each domain.  The important part for you to remember is that every hour, inheritance on these protected groups will be removed and SendAs will be wiped away.

A good blog article explaining what adminSDHolder and SDprop are and what Protected Groups  is located here.



The Missing Manual Part 1: Veeam B & R Direct SAN Backups

Posted on by

One thing that I had problems with the first time I installed Veeam was the ability to backup Virtual Machines directly from the SAN. Meaning that instead of proxying the data through an ESXi host, the data would flow from SAN to backup server directly. The benefits of this process are very clear… reduced CPU and network load on the ever so valuable ESXi resources.

The problem is that by default this just doesn’t work with Veeam if you haven’t properly setup your backup server. I will try and keep this process simple, and vendor agnostic ( from a SAN point of view).

The first step to making the vStorage API “SAN backup” work is to make sure your backup server has the Microsoft iSCSI initiator installed. It is already installed by default on Windows 2008 server, however for windows 2003 server you will need to go to Microsoft to download the latest version. (Note: You will need to configure your SAN to allow the IQN address of the iSCSI initiator to have access to the volumes on the SAN… this process is different for each vendor. See screen shot on how to find this in the Configuration tab of the iscsi initiator) After installing MS iSCSI initiator, and setting up your SAN, we need to configure it to see the SAN volumes; do this by opening the “iSCSI initiator” option from control panel. At the top of the main tab there is a field where you can put your SAN’s IP address, enter that now and then press Quick Connect. Shortly a list of all of the volumes that your backup server has access to should appear, once they do select each one and press the “connect” button. Because the volumes are formated VMFS windows will not show them in My Computer, but if you go to Disk Management inside of Computer manager you should now see that the backup server can see these volumes.

Update: A note from the Veeam Team “One thing that we (Veeam) recommends is to disable automount on your Windows backup server. To do this open up a command prompt and enter in diskpart. Hit enter and then type “Automount disable”. This is to ensure that the Windows server doesn’t try and format the volumes at all. However, before any of this is done if you can through your SAN software, give the Veeam Backup server Read-Only access to your VMFS volumes.”

After preforming these steps go ahead and configure Veeam to use the SAN backup option, and you should notice (especially if you have separate NICs for the SAN network) that all of your data is moving through the SAN directly to the backup server without proxying through the ESXi hosts.