shop high quality replique rolex.

discover the luxury rolex imitacion online watch store.

replica watches are the best qulity online.

swiss replica watches owns a high factor within throughout the world watch business sector.

richard mille fakes are the perfect mix between italian design and swiss technology at the service of the passion for the sea.

MVP - Most Valuable Professional
rss

Just can't get enough of IT

This blog is about mostly anything in IT. But the primary focuses are Microsoft technologies like Exchange Server, Microsoft 365, Microsoft Teams, and Cloud Security.
Thomas Stensitzki | MVP
Thomas Stensitzki | MVP

MVP LogoThomas Stensitzki is a leading technology consultant focusing on the Microsoft messaging and collaboration technologies and the owner of Granikos GmbH & Co. KG.

He is an MVP for Office Apps & Services since 2018.

Thomas is an MCT Regional Lead for Germany and delivers Microsoft Learning training courses for Office 365, Microsoft Teams, and Exchange Server.

He holds Master certifications as Microsoft Certified Solutions Master Messaging and as Microsoft Certified Master for Exchange Server 2010. These certifications make him a subject matter expert for any messaging topic related to Microsoft Exchange, Exchange Online, Microsoft 365, and hybrid configurations.

Follow Thomas: LinkedIn, Twitter

His sessions: https://sessionize.com/thomas-stensitzki

MVP Blog: https://blogs.msmvps.com/thomastechtalk
Personal blog: http://justcantgetenough.granikos.eu
Personal website: http://www.stensitzki.de
Thomas' Tech Talk: youtube.com/ThomasStensitzki

Contact Thomas at thomas@mcsmemail.de

 

Last updated: 2020-09-17

 

Exchange Server 2010Exchange Server 2013Exchange Server 2016Exchange Server 2019Problem

The use of Exchange Edge Transport Servers requires the synchronization of user and configuration data from internal Exchange Servers to the Edge Transport Servers. The synchronization utilizes secure LDAP (EdgeSync) to transmit the data securely and is based on an Edge Subscription.

When you create a new Edge Subscription on your internal Exchange Servers by importing the Edge Subscription XML-file, establishing the EdgeSync-connection might fail.

You will find the following error in the application event log of the internal Exchange Server:

Log Name:      Application
Source:        MSExchange EdgeSync
Event ID:      1035
Task Category: Synchronization
Level:         Error
Keywords:      Classic
Description:
EdgeSync failed to synchronize because it only supports Cryptographic API certificates. 
The local Hub Transport server's default certificate with thumbprint XYZ isn't a 
CAPI certificate. To set a CAPI certificate as the default certificate, use the 
Enable-ExchangeCertificate cmdlet with the Services parameter using the value of SMTP.
When you encounter this error I recommend removing the Edge Subscription from the internal and the Edge Transport Server. Fixing this issue will take some time and the Edge Subscription might become invalid.

 

Reason

The private key of the current Exchange Transport default certificate of the internal Exchange servers uses a CNG private key. EdgeSync requires a CAPI1 based private key.

  • CNG = Cryptography Next Generation
  • CAPI1 = Cryptographic API (already deprecated)

This problem occurs primarily when using an Enterprise Certificate Authority using certificate templates with individual template settings. 

So far, I have not seen this issue when using public certificates issued by trusted 3rd-party Certificate Authorities.

 

How do you determine, if the type of the default transport certificate is a CNG or CAPI1 certificate?

  • Log on to the internal Exchange Server where you imported the Edge Subscription file and start a new Exchange Management Shell session
  • Query the Transport Service to identify the default certificate thumbprint
Get-TransportService | ft Name,InternalTransportCertificateThumbprint
  • Open an administrative command prompt
  • Export the certificates information from the certificate store to a text file
certutil -v -store my > cert.txt
  • Open the text file using an editor tool of your choice
  • Search for the certificate thumbprint identified in step 2
    This thumbprint is the SHA1 certificate hash
  • Scroll down to the provider section to find the following two attributes
    • ProviderType
    • KeySpec

If both attribute are of the value 0, the certificate if a CNG certificate.

The section might look like this:

Unique container name: XYZ
    Provider = Microsoft Software Key Storage Provider
    ProviderType = 0
  Flags = 20 (32)
    CRYPT_MACHINE_KEYSET -- 20 (32)
    KeySpec = 0 -- XCN_AT_NONE

 

Solution

Use OpenSSL to convert the CNG certificate to a CAPI1 certificate.

Using OpenSSL requires the download of the Windows release of OpenSSL. I recommend to not install the software on the Exchange Server but a separate Windows server or your administrative desktop system. Additionally, you need the certificate with its private key as a PFX-file.

Use the following steps to convert the CNG certificate to a CAPI1 certificate.

  • Download and install OpenSSL
  • Open the OpenSSL Command Prompt
  • Navigate to the folder containing the PFX-file
  • Convert the PFX-file to a PEM-file
    The tool will query to enter the PFX password
openssl pkcs12 -in CERT.pfx -out cert.pem -nodes
  • Convert the PEM-file to a new PFX-file
    The tool will query you to set a PFX password
openssl pkcs12 -export -in cert.pem -out NEWCERT.pfx

The new PFX-file is now a CAPI1 certificate. The new certificate has the same thumbprint. Now you must replace the current certificate used by Exchange Server with the new certificate. 

Replacing the certificate requires a downtime of each Exchange Server requiring the certificate replacement. This is due to the requirement to remove the CNG certificate first, following the import of the CAPI1 certificate. Afterward, you need to enable the required Exchange services.

  • Log on to the internal Exchange Server where you imported the Edge Subscription file and start a new Exchange Management Shell session
  • Query local Exchange Server certificates and identify the thumbprint of the default Exchange Server self-signed certificate 
    The certificate common name (CN) equals the server name
Get-ExchangeCertificate -Server SERVERNAME
  • Change the Exchange Transport default certificate to the self-signed certificate before deleting the CNG certificate
# It is mandatory to answer the query for replacing the default certificate with YES
Enable-ExchangeCertificate -Thumbprint THUMBPRINT -Services SMTP

# Restart the transport service
Restart-Service MSExchangeTransport
  • Remove the CNG certificate
    • Use either the certificate store MMC, Exchange Management Shell, or Exchange Admin Center
  • Import the CAPI1 certificate
    • Use either the certificate store MMC, Exchange Management Shell, or Exchange Admin Center
  • Enable the imported certificate and replace the default transport certificate
# It is mandatory to answer the query for replacing the default certificate with YES
Enable-ExchangeCertificate -Thumbprint NEWCERTTHUMBPRINT -Services SMTP

# Restart the transport service
Restart-Service MSExchangeTransport
  • Repeat the certificate replace for each Exchange Server in the same Active Directory site

 

Now, that you updated the local Exchange Servers there is one more step that needs to be checked on the Edge Transport Servers.

Edge Transport Servers are not domain-joined and therefore do not receive any GPO-based configuration. Each required configuration must be performed locally. To ensure that the default transport certificate of the internal Exchange servers can be used for cryptographic operations we must ensure that the certificate chain of that certificate is present in the certificate store of Edge Transport servers.

Take a look at the certificate chain of the converted CAPI1 certificate and import the Root-CA and Subordinate-CA certificates into the Edge Transport servers local certificate store. You must ensure that the certificates are placed into appropriate stores:

  • Root-CA certificate goes into Trusted Root Certification Authorities \ Certificates
  • Subordinate-CA certificate goes into Intermediate Certification Authorities \ Certificates

 

Next, you create a new Edge Subscription on your Edge Transport server and create a new subscription for the Active Directory site on the internal Exchange Server. The internal Exchange Servers are now able to establish an EdgeSync connection and encrypting the data transferred to the Edge Transport servers.

 

Note

When you receive the TLS certificate as PFX/PKCS12 file, you import the certificate and the private key. The import process itself defines the priavte key Crypto Provider. Using the following command line you ensure that the import process suses the legacy crypto provider.

certutil -csp "Microsoft RSA SChannel Cryptographic Provider" -importpfx my MYCERTpfx

 

Links

 

Enjoy Exchange Server and Edge Transport!

 

Are you located in Germany, Austria, or Switzerland? Join the Exchange User Group DACH to collaborate with other Exchange enthusiasts.
Follow us on Twitter @exusg, join on Meetup, or visit our website

Read More »

Exchange Server LogoExchange Server uses Receive Connectors for providing SMTP endpoints for incoming connections. A modern Exchange Server provides a default connector on TCP port 25. 

Sometimes you might have a requirement to create a new receive connector for selected incoming SMTP connections. A standard requirement is a receive connector for relaying messages to external recipients. This cannot (should not) be achieved using the default connector.

Each connector uses the RemoteIPRanges attribute to store the list of IP addresses of remote systems that can connect to that connector. The default connector utilizes the full IPv4 and IPv6 addresses ranges.

Your new receive connector requires at least a single IP address for a selected remote system that is supposed to connect to that receive connector. You can add a single IP address, address ranges, or IP addresses using CIDR notation.

The attribute RemoteIPRanges is a multi-value attribute and has a limit of IP address entries that can be added. 

The maximum number of address entries that you can add to that attribute varies. You can store approximately 1,300 entries.

When you exceed the number of values you receive the following error message:

The administrative limit for this request was exceeded.
    + CategoryInfo          : NotSpecified: (:) [Set-ReceiveConnector], AdminLimitExceededException
    + FullyQualifiedErrorId : [Server=EX01,RequestId=ee9d45ad-418b-4172-9235-963eca1a7830,TimeStamp=18.08.2020
    20:07:54] [FailureCategory=Cmdlet-AdminLimitExceededException] AC1E336E,Microsoft.Exchange.Management.SystemConfi
  gurationTasks.SetReceiveConnector
    + PSComputerName        : ex01.varunagroup.de

 

I have tested the number of values that can be stored in that multi-value attribute. Depending on the IP address format I was able to add 1,238 (172.80.x.y) or 1,244 (10.1.x.y) single IP addresses to the RemoteIPRanges attribute.

Plan your IP address configuration requirements carefully and avoid using single IP addresses. Preferably, you should use IP address ranges or IP address CIDR notation for networks.

 

Links

 

Enjoy Exchange Server!

 

Are you located in Germany, Austria, or Switzerland? Join the Exchange User Group DACH to collaborate with other Exchange enthusiasts.
Follow us on Twitter @exusg, join on Meetup, or visit our website

 

Read More »

The Microsoft 365 Virtual Marathon took place on May 27-28 2020.

The recording of my session "Exchange Hybrid - What, Why, and How" is available on YouTube. 

 

Browse all recordings of the Microsoft 365 Virtual Marathon here: https://www.youtube.com/channel/UCrtmT6Ir1MIs0ZES7sKMmqA

Enjoy!

 

 

Read More »
Last updated: 2021-02-02


Logo Exchange ServerThis is a post summarizing the configuration values for important Exchange-related Active Directory object attributes.

Whenever you need to look up these values for troubleshooting, or editing the values manually.

Note: You should not edit any of the values manually, just because you can. Edit any Exchange-related attributes, if you are familiar with the result of your changes.

 

RemoteRecipientType

Attribute

  • msExchRemoteRecipientType 

 

1
ProvisionMailbox
2
ProvisionArchive (On-Premises Mailbox)
3
ProvisionMailbox, ProvisionArchive
4
Migrated (UserMailbox)
6
ProvisionArchive, Migrated
8
DeprovisionMailbox
10
ProvisionArchive, DeprovisionMailbox
16
DeprovisionArchive (On-Premises Mailbox)
17
ProvisionMailbox, DeprovisionArchive
20
Migrated, DeprovisionArchive
24
DeprovisionMailbox, DeprovisionArchive
33
ProvisionMailbox, RoomMailbox
35
ProvisionMailbox, ProvisionArchive, RoomMailbox
36
Migrated, RoomMailbox
38
ProvisionArchive, Migrated, RoomMailbox
49
ProvisionMailbox, DeprovisionArchive, RoomMailbox
52
Migrated, DeprovisionArchive, RoomMailbox
65
ProvisionMailbox, EquipmentMailbox
67
ProvisionMailbox, ProvisionArchive, EquipmentMailbox
68
Migrated, EquipmentMailbox
70
ProvisionArchive, Migrated, EquipmentMailbox
81
ProvisionMailbox, DeprovisionArchive, EquipmentMailbox
84
Migrated, DeprovisionArchive, EquipmentMailbox
100
Migrated, SharedMailbox
102
ProvisionArchive, Migrated, SharedMailbox
116
Migrated, DeprovisionArchive, SharedMailbox

 

Recipient Type 

Attribute

  • msExchRecipientDisplayType

 

Display Type
msExchRecipientDisplayType
(Decimal Value)
RecipientType
Mailbox User
0
MailboxUser
Distribution Group
1
DistrbutionGroup
Public Folder
2
PublicFolder
Dynamic Distribution Group
3
DynamicDistributionGroup
Organization
4
Organization
Private Distribution List
5
PrivateDistributionList
Remote Mail User
6
RemoteMailUser
Conference Room Mailbox
7
ConferenceRoomMailbox
Equipment Mailbox
8
EquipmentMailbox
ACL able Mailbox User
1073741824
ACLableMailboxUser
Security Distribution Group
1043741833
SecurityDistributionGroup
Synced Mailbox User
-2147483642
SyncedMailboxUser
Synced UDG as UDG
-2147483391
SyncedUDGasUDG
Synced UDG as Contact
-2147483386
SyncedUDGasContact
Synced Public Folder
-2147483130
SyncedPublicFolder
Synced Dynamic Distribution Group
-2147482874
SyncedDynamicDistributionGroup
Synced Remote Mail User
-2147482106
SyncedRemoteMailUser
Synced Conference Room Mailbox
-2147481850
SyncedConferenceRoomMailbox
Synced Equipment Mailbox
-2147481594
SyncedEquipmentMailbox
Synced USG as UDG
-2147481343
SyncedUSGasUDG
Synced USG as Contact
-2147481338
SyncedUSGasContact
ACL able Synced Mailbox User
-1073741818
ACLableSyncedMailboxUser
ACL able Synced Remote Mail User
-1073740282
ACLableSyncedRemoteMailUser
ACL able Synced USG as Contact
-1073739514
ACLableSyncedUSGasContact
Synced USG as USG
-1073739511
SyncedUSGasUSG

 

 

  • Exchange Server: msExchRecipientTypeDetails
  • Exchange Online: RecipientTypeDetails

 

Object Type
msExchRecipientTypeDetails
(Decimal Value)
RecipientTypeDetails
User Mailbox
1
UserMailbox
Linked Mailbox
2
LinkedMailbox
Shared Mailbox
4
SharedMailbox
Legacy Mailbox
8
LegacyMailbox
Room Mailbox
16
RoomMailbox
Equipment Mailbox
32
EquipmentMailbox
Mail Contact
64
MailContact
Mail User
128
MailUser
Mail-Enabled Universal Distribution Group
256
MailUniversalDistributionGroup
Mail-Enabled Non-Universal Distribution Group
512
MailNonUniversalGroup
Mail-Enabled Universal Security Group
1024
MailUniversalSecurityGroup
Dynamic Distribution Group
2048
DynamicDistributionGroup
Public Folder
4096
Public Folder
System Attendant Mailbox
8192
SystemAttendantMailbox
System Mailbox
16384
SystemMailbox
Cross-Forest Mail Contact
32768
MailForestContact
User
65536
User
Contact
131072
Contact
Universal Distribution Group
262144
UniversalDistributionGroup
Universal Security Group
524288
UniversalSecurityGroup
Non-Universal Group
1048576
NonUniversalGroup
Disabled User
2097152
DisabledUser
Microsoft Exchange
4194304
MicrosoftExchange
Arbitration Mailbox
8388608
ArbitrationMailbox
Mailbox Plan
16777216
MailboxPlan
Linked User
33554432
LinkedUser
Room List
268435456
RoomList
Discovery Mailbox
536870912
DiscoveryMailbox
Role Group
1073741824
RoleGroup
Remote Mailbox
2147483648
RemoteMailbox
Team Mailbox
137438953472
TeamMailbox
Remote Team Mailbox
274877906944
RemoteTeamMailbox
Monitoring Mailbox
549755813888
Monitoring Mailbox
Group Mailbox
1099511627776
GroupMailbox
Linked Room Mailbox
2199023255552
LinkedRoomMailbox
AuditLogMailbox
4398046511104
AuditLogMailbox
Remote Group Mailbox
8796093022208
RemoteGroupMailbox
Scheduling Mailbox
17592186044416
SchedulingMailbox
Guest MailBox
35184372088832
GuestMailBox
Aux AuditLog Mailbox
70368744177664
AuxAuditLogMailbox
Supervisory Review
140737488355328
SupervisoryReview

 

 

Read More »

Microsoft 365 Groups are the backbone of various Microsoft 365 workloads. As you might know, each group utilizes a SharePoint site collection, and an Exchange shared mailbox.

When you create a new Microsoft 365 group, SharePoint Online must store the associated site collection somewhere. SharePoint Online uses predefined paths to determine the storage location. These paths are called: Managed Paths.

SharePoint Online uses two different pre-configured managed paths:

  • /sites
  • /teams

With /sites as the default setting for the Microsoft 365 tenant.

Whenever you create, e.g., a new team in Microsoft Teams, the associated site collection is stored in https://TENANTNAME.sharepoint.com/sites/TEAMNAME. As a SharePoint administrator, you see the site collection paths in the list of active sites in the SharePoint Admin Center.

Screenshot SharePoint Online Active Sites

 

But what can you do, if you want to store the associated site collections in the /teams managed path?

 

Changing the Managed Path

The SharePoint Admin Center provides you with an option to change the managed path for sites, created by users. 

Open the SharePoint Admin Center, navigate to Settings -> Site Creation.

Screenshot SharePoint Admin Center Settings -> Site Creation

 

Change the setting for Create team sites under to /teams/.

Screenshot SharePoint Admin Center - Site creation

 

The description of this setting is misleading. This setting affects not only SharePoint team site creation initiated by users on the SharePoint start page or OneDrive, but site collections created by Microsoft 365 Groups as well.

You do not need to enable the checkbox to let users create sites from the SharePoint start page and OneDrive. This setting is only required, when you want to enable self-service site creation of modern SharePoint sites for users. The modern SharePoint sites are based on Microsoft 365 Groups.

After changing the path, SharePoint Online creates new associated site collections for Microsoft 365 Groups in /teams/.

Screenshot - SharePoint Admin Center - Active Sites

 

Note:
Changing this setting affects Microsoft 365 Groups in general. It does not, which Microsoft 365 app you use to create a new group.
The associated site collection for a new plan in Planner, a new team in Microsoft Teams, a new Group in Outlook on the Web, or even a new website in OneDrive, is created using this configured path.

 

Enjoy SharePoint Online.

 

 

Read More »
0123movie.net