Showing posts with label Copiers. Show all posts
Showing posts with label Copiers. Show all posts

Thursday, 7 June 2018

Exchange 2013+: Set Up a Receive Connector for MFP/Copier/Device Relay

The following are the two steps required to enable an internal anonymous relay in Exchange 2013/2016/20*.

Step 1: Create the Receive Connector

New-ReceiveConnector –Name MFP-APP-AnonRelay –Usage Custom –Bindings 0.0.0.0:25 –RemoteIPRanges 192.168.25.1-192.168.25.10,192.168.25.225-192.168.25.254 –Comment “Allows anonymous relay” –TransportRole FrontEndTransport –AuthMechanism None –PermissionGroups AnonymousUsers

Variables:

  • -Name: Change this if needed but must match for both steps
  • -RemoteIPRanges: Only put trusted device IP addresses in this section

Once the receive connector is set up it can be managed via EAC.

Step 2: Allow Anonymous Rights

Get-ReceiveConnector “MFP-APP-AnonRelay” | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient”

Variable:

  • The Receive Connector name must match the one set in Step 1

Conclusion

Once the above steps are set up there is no need to set a username and password on any device that has an allowed IP.

For obvious reasons one should never put an Internet IP address in this rule! But, that being said, one always denies all SMTP 25/587 inbound traffic to a third party sanitation provider's subnets right (we use ExchangeDefender for our own and our client's needs)?

Also, this setup is for on-premises Exchange.

Philip Elder
Microsoft High Availability MVP
MPECS Inc.
Co-Author: SBS 2008 Blueprint Book
Our Web Site
Our Cloud Service

Monday, 23 July 2012

Canon Copier Network Print Using PCL6 Driver Error: NG End Code #853

Apparently Canon has a licensing fee for enabling PCL printing via a network.

We just finished setting up a network with three Canon copiers on it. One did not print:

image

In the above snip we see the failures and subsequent success when printing.

The catch was the need to change the PCL6 driver for the Canon UFR II and then re-deploy the copier via Group Policy.

image

As the snip shows the copier was happy once we corrected the driver.

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
Co-Author: SBS 2008 Blueprint Book

*Our original iMac was stolen (previous blog post). We now have a new MacBook Pro courtesy of Vlad Mazek, owner of OWN.

Windows Live Writer

Saturday, 5 September 2009

SBS 2008 – MFP/Copier To Scan To E-mail Destined To A Companyweb SharePoint Library How To

One of our clients picked up a new Konica Minolta copier (previous blog post).

One of the requirements for the new copier was to have it scan documents and e-mail them to various users on the network. Another requirement was to have the copier scan documents to a folder.

Well, the folder idea was a bit of a pain due to the password rotation policies in place. We would end up either requiring that a restricted user be created with a pass phrase that never changes, or look for another method.

Since the copier was able to scan to e-mail, the simplest solution seemed to be to have it e-mail the attached PDF or other file to a Companyweb SharePoint Library.

The process was much easier said than done, though we managed to get things ironed out this afternoon with a lot of patience on the part of our client contact.

So, here are the steps we took in the order we took them along with a couple of errors we made during the whole process. Because of that, please read the entire post before heading out to make these configuration changes.

Configure the E-mail Enabled SharePoint Library

The first step in this process is to create the new document library that will be the destination for our copier e-mailed attachments.

We need to be logged into a workstation as either the domain admin or with a user account that has admin rights to the Companyweb site.

We click on the Site Actions button near the top right of the site and we create our new library:

image

Add a description if need be and click the Create button. Make sure to pay very careful attention to the information inputted in these fields.

Once the library is created, click on the Scans link now below the Fax Center in our own situation to bring it up:

image

Create a New Receive Connector

Our next step is done on the SBS 2008 server itself.

In the Exchange Management Console, here we are using Windows SBS Native Tools Management, we need to get to the Hub Transport role under the Server Configuration Node:

image

Right click anywhere under the Receive Connectors list and click on New Receive Connector:

image 

We name the Receive Connector. In our case we called it Copier Send to E-mail.

After clicking next, we will leave the default local SMTP receive settings alone when it comes to the local IP addresses.

image

Take note however, that the FQDN setting needs to be filled out with the SBS server’s Fully Qualified Domain Name: MY-SBS.MySBSDomain.Local.

Next we have the From IPs. This is where we input the copier’s IP address. We added both copiers if they decided they wanted the other one e-mail enabled,

image

Once we click Next we are given a summary of the changes about to be made. We then clicked the New button to make it happen.

Receive Connector Properties

Once the Receive Connector has been created, we need to tweak it a bit to allow for anonymous SMTP connections from our two copier IP addresses.

Right click on the Copier Send To E-mail connector and click on Properties.

Click on the Authentication tab and make sure none of the check boxes are checked:

image

Then click on the Permissions Groups tab and put a check mark beside the Anonymous users setting:

image 

Our last step with regards to our Receive Connector is to run an Exchange Management Shell command to set the anonymous permissions into play:

  • Get-ReceiveConnector "Copier Send To E-mail" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Recipient"

Open the Exchange Management Shell by right clicking on it and then clicking on Run As Administrator.

Copy and paste the above command into the Management Shell. Note that the name of the Receive Connector in our example needs to be changed to whatever you have named the Receive Connector in order for things to work as expected.

This is what a successful command will look like:

image

We now have our SBS Exchange set up to allow the copiers to relay e-mail containing any scanned items through it.

Create An E-mail Enabled Contact

Our last step in this process is to create an e-mail enabled contact.

The e-mail address we created for the library was: Scans@companyweb. Companyweb is not a known or enabled e-mail domain anywhere in our SBS setup other than the SharePoint library and Exchange.

There may be a need for users to e-mail content into the library via their Outlook client, so we create the new contact.

Coming back to our open Windows SBS Native Tools Management console with the Exchange Management Console opened, we need to click on the Recipient Configuration node.

In the right hand Actions column click on New Mail Contact.

Fill out the Contact Information taking care to note that the Alias should be the same value as the e-mail address prefix (_____@MySBSDomain.Local):

image

Click the Edit button next to the pencil to get:

image

Now for clarification’s sake, have a look at what was typed into the E-mail address field in this pop-up and head back up to the SharePoint library e-mail address. Notice any difference?

When everything was put together we could not get an e-mail to the SharePoint library but we could to the users when a scan was initiated at the copier. Somehow, through the whole process the e-mail address was seemingly case sensitive in Exchange and/or in the SharePoint library. The other possibility was that the address in the copier was different and the copier was case sensitive for e-mail.

Either way:

  • Make sure the e-mail address used is consistent case sensitivity wise throughout the set up process.

With that in mind, our input should have been: Scans@companyweb as it was in the SharePoint library.

Here is the filled out Contact Information step:

image

After clicking Next we are presented with a summary of the settings. Click the New button and we will now have an e-mail contact that will show up in the GAL thus allowing

Restart the Microsoft Exchange Transport Service

Once we have all of our configuration changes in place, as an extra precaution we restarted the Transport Service:

image

Test Scans

So, once we have the configuration in place everything should work as expected right?

Well . . . no.

The photocopier folks had their training person in to work with our client’s users on learning the copier and its features.

We did not have the scan to e-mail enabled before they arrived. When things did not work as expected, they made some changes on the copier according to our client contact.

Now, the copier needs to send e-mail to that library. The library uses what is essentially an Internet non-existent e-mail domain.

Here is the setting change that was made:

image

Notice the problem setting?

Our local Shaw SMTP server setting was put in the place of our client’s SBS IP address.

E-mail would flow to the users but not to the library.

Once we corrected that, we still could not get e-mail to flow.

We fired up the Exchange E-mail tracking to find out if the copier was even connecting to the server:

image

It was, but the e-mail was not reaching the library.

This is when we figured out that the only anomaly that we could see in the entire chain of events was the case in the e-mail address.

Once we had the e-mail address case settings the same in the:

  • Copier address list.
  • Exchange e-mail enabled contact.
  • SharePoint document library

We had the following result:

image

Our first PDF scan hits the library!

One of the neat things about this setup is the Alerts feature in SharePoint libraries. If there are one or two folks responsible for keeping the library tidy then anytime an e-mail attachment hits the library they can put the bug in someone’s ear to take care of it.

Overview steps:

  1. Configure the E-mail Enabled SharePoint Library.
  2. Create a New Receive Connector.
  3. Modify the Receive Connector's Properties.
  4. Create an E-mail Enabled Contact.
  5. Restart the Microsoft Exchange Transport Service.
  6. Test Scans and Troubleshooting.

Links

The above was brought about via a combination of resources:

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
Co-Author: SBS 2008 Blueprint Book

*All Mac on SBS posts will not be written on a Mac until we replace our now missing iMac! (previous blog post)

Windows Live Writer

Tuesday, 1 September 2009

SBS 2008 – Konica Minolta BizHub C353 Driver GP Stall

One of our clients called to say that they had a new copier being installed at their site and if we would mind popping by to help out with the install.

It seemed like a pretty straight forward task and we had a bit of time in-between calls so the call came in at an opportune time.

We downloaded what we thought were the newest drivers for the unit:

image

Now, the 64bit driver installed into the Print Management drivers node with no real issue.

But, when we went to install the 32bit drivers after configuring the printer, adding it to the SBS 2008 Console, and deploying it via Group Policy we received this surprise:

image

Add Printer Driver Wizard

The selected driver must be installed remotely from an x86 computer using Type 3 (User mode) drivers.

Okay . . . now how exactly does that work again?

Since this was the first time we had seen this message, a bit of searching ensued to figure out how.

That was a tough find:

image

We needed to navigate to \\MY-SBS\Printers and open the Server Properties, bring up the driver dialogue and “upload” the drivers onto the server from an x86 system as the error message indicated.

But, something still did not jibe.

So, we went back to Konica Minolta’s Web site for the copier to see just what was going on with the drivers.

Now, what is happening right now, this evening, as this post is being written is pretty funky. The driver results page looks different than it did this afternoon while at the client site.

Here is what the driver site looks like now.

Windows Vista 32-Bit Postscript Drivers:

image

Windows Vista 32-Bit PCL Drivers:

image

Windows Vista 64-Bit Postscript Drivers:

image Windows Vista 64-Bit PCL Drivers:

image

Now, after looking at all of the drivers, we knew that the Universal Driver was going to be a problem.

We did need a WHQL signed driver though.

The original driver we had downloaded was both the Postscript and PCL 6.1.2.0 driver sets. After extracting them, we found that they contained both x86 and x64 driver directories. It was the 6.1.2.0 x86 driver that was giving us the headache on SBS 2008.

So, on the second venture through the site, we looked at every driver option for the copier and one eventually stood out as the candidate for our solution.

Can you guess which one?!? :)

Yes, it was the 6.3.1.0 driver set dated June 24, 2008 that was our only other specific driver with a WHQL signature. Only, it was not an option for Vista 32bit where we looked for the 32bit drivers in the first place!

We downloaded, extracted, and ran the Add Driver routine in the Print Management console.

Sure enough, the 64bit driver updated to 6.3.1.0 and the 32bit 6.3.1.0 driver installed via the console with no issues either.

Once we had the driver in place, we ran our workstation reboot script and we had all of our Windows Vista x86 machines connected to the new copier.

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
Co-Author: SBS 2008 Blueprint Book

*All Mac on SBS posts will not be written on a Mac until we replace our now missing iMac! (previous blog post)

Windows Live Writer