Cross-site publishing, and particularly Product Catalogs have been missing from the SharePoint 2013/v16 rev of SharePoint Online, leaving a large gap in functionality between on-premises deployments and our Cloud overlords. Reading the Service Description, both WCM: Catalog and WCM: Cross-site publishing are listed as "Not available to SharePoint Online customers."
It appears however, that it’s all about to change. While editing a page in one of my tenants today, I noticed a few changes:
All that is missing now is that magical ability to create a Product Catalog site collection.
Coming in March 2013, following the release of the next version of Office 365, users will be presented with a streamlined sign-in experience. The sign-in page will a feature responsive design and was designed to “provide the best possible performance and experience on computing devices”.
If you’d like to opt-in earlier and test drive the new experience, click here.
Post opt-in, here’s what you’ll experience on the desktop.
There are several characters that can come off your keyboard that can make life with Office 365 a little painful, especially in a coexistence scenario. One such pain point is the use of special characters like an apostrophe (‘) in user principle names and email addresses. Please note that it is not possible to utilize an alias with an apostrophe in a non-coexistence scenario as the Exchange Online administration screens will not allow you to create the alias with illegal characters.
If you have any users like this in your environment, the first step is to transition them over to a user name that does not make use of an apostrophe (or any other illegal characters) and also ensure that their primary email address (under the Proxy-Addresses attribute in Active Directory) does not contain any illegal characters as well. If your users have illegal characters in their user name, they will experience errors similar to those found in KB2439357 - Error message when you try to create a user name that contains a special character in Office 365: “Invalid user name”.
After the user has been properly configured, they will be able to send and receive messages via an alias that contains an apostrophe.
The following table details the special characters and their usage scenarios in Office 365 for user names, passwords, and email addresses (see Characters in passwords or user names in Office 365 for the original. I’ve added the email address column here).
|Character Name||Character||Allowed In|
|User Name||Password||Email Address|
|Angle Brackets||< >||No||Yes||No|
|Uppercase Letters (A-Z)||A-Z||Yes||Yes||Yes|
|Lowercase Letters (a-z)||a-z||Yes||Yes||Yes|
* You can put a period or hyphen anywhere in your user name or email address except at the very beginning or at the very end.
** You can put an underscore anywhere in your user name, including at the very beginning or at the very end.
*** Apostrophes can be used in non-primary email addresses (aliases) for both receiving and sending messages.
Any user who wishes to make use of an email address with an apostrophe will need the additional addresses created within the source domain. A domain administrator or user with rights to update the Proxy-Addresses attribute within Active Directory should add the applicable aliases on behalf of the user.
For instance, if the user Demo O’Reilly (UPN email@example.com) wishes to have an additional alias provisioned for the address demo.o’firstname.lastname@example.org, an additional proxy address of smtp:demo.o’email@example.com should be applied to the user’s account in Active Directory. After the applicable proxy addresses have been applied, a Directory Synchronization (DirSync) should occur (either manually initiated or on the existing schedule) before the email address will be available for use in Exchange Online. After DirSync has completed, an Office 365 Exchange Administrator can verify that the alias has been applied to the user’s federated account.
After an Office 365 Exchange Administrator has verified that the alias has been created successfully, a test message should be sent to the user to verify that messages are being routed as intended. Note that the messages will be routed to the users primary email address (e.g. firstname.lastname@example.org).
This is where the magic happens. As Outlook Web Access does not support multiple “From” accounts, we need to configure a 3rd-party client (in this case Outlook) to allow our user to send messages using their new alias. We’re going to be using the directions found at How to add an alias to an Office 365 account and how to set up Outlook to send email messages as this alias.
The following configuration steps will allow you to connect to the BPOS OCS servers: