Few days ago, I noticed that SCCM (version 1606) packages failed to distribute to Distribution Point. This is valid for new or existing packages. SCCM was unusable. So, it is a big mess.

After analysis, I found error bellow:

Distribution Manager failed to access the source directory “\\share\folder\sourcefile” for content “ContentName” (Content ID=0000000).

Possible cause: Distribution Manager does not have sufficient rights to the source directory.

Solution: Verify that the site server computer account has at least Read access to the directory you specify as the source directory.

Possible Cause: There is not enough disk space available on the site server.

Solution: Verify that there is enough free disk space available on the site server.

I checked permissions. Site Manager Computer Account (Contoso\SCCM) is member of local Administrator group. Source folders permissions are OK.

SCCM Site server has plenty of free space.

So, everything seems OK, but errors are still present.

Solution:

I think that the best thing in such case is to Reset SCCM Site Server with no configuration changes.

During the Site Reset with no configuration changes, all site components are reinstalled, and permissions and registry keys are restored to their default settings.

I run setup.exe from “C:\Program Files\Microsoft Configuration Manager\bin\X64” (folder, where you can find your SCCM installation files)

I select option: Perform site maintenance or reset this site 

After this I select: Reset site with no configuration changes

Process is finished in few minutes. After that, I noticed that first packages are distributed to distribution point. Error has gone!!! SCCM works well!!!  🙂 

Distributed Cache in SharePoint is very good, but after some time, its content becomes old. The first user who visits specific SharePoint Site, which was not visited for longer time, has to wait many seconds that Site Web Page opens, because Distributed Cache has to refresh its content. This is not optimal user experience and could be annoying.

Solution:

If I would like to solve the problem, I have to create a script that would run on schedule.

One option is to open specific Site Web Page in browser, but it is problematic, because in this case I have to run specific browser many times and script will probably fail on long run.

Better option is to use WebClient.DownloadString Method, which can download Web Page as string.

First of all I have to enable access to SharePoint Site from the same machine, where SharePoint is hosted. Windows Server has integrated loopback security feature that prevents me to access SharePoint Site from SharePoint hosted Server. I can enable access to SharePoint Site using Registry (regedit.exe).

I have to find registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0

and add registry Multi-String Value:

BackConnectionHostNames with all desired FQDN from which I want to access SharePoint Sites (for instance spca.contoso.com, sp.contoso.com, …).

You have to restart SharePoint server to apply upper settings. SharePoint Sites from above list should be accessible using browser (Internet Explorer) on SharePoint server.

Next, I have to create PowerShell script (for instance OpenSP.ps1), that is needed to download Web Page as string:

Above script should be run as user that has rights to open SharePoint Web Site (for instance Contoso\SPAdmin). User’s credentials will be provided while opening SharePoint Web Site.

You can’t provide specific credentials in script, because using Windows Authentication SharePoint Site will never authenticated specified user.

Save PowerShell script in Windows Folder (for instance C:\Scripts).

In the last step I have to create Task using Windows Server Task Scheduler.

Task should be run as user account that has rights to open SharePoint Web Site (Contoso\SPAdmin) and it should run whether user is logged on or not.

Task is triggered every hour indefinitely (you can select different scheduler).

In Task Action, I select to run a program: PowerShell.exe with arguments: -ExecutionPolicy Bypass “C:\Scripts\OpenSP.ps1”

You can download xml file, that you can use to import sample Task into Task Scheduler:

Open sp.contoso.com.xml.

That’s all. Now users will not have problems visiting SharePoint Site anymore!!! 🙂 

You can use the same script to refresh different Web Pages, when you see that it could be useful.

If we look at Windows Server and Windows Client OS Event Log, we can see Events 10016:

The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID … and APPID …
This means that specific user does not have local launch and local activation permission to run specific DCOM object.

For instance we can look at fresh installed Windows 10 (version 1607 – Anniversary Update).

If we look at System Windows Log in Event Viewer, we can find this type of Error:

In this example user System does not have permission to Local Launch (Local Activation) DCOM Application with ID: {F72671A9-012C-4725-9D2F-2A4D32D65169}.

Solution:

We have to set DCOM Application permissions for specific user in Component Services (we have to launch app as Administrator).
Then we have open Component Services, Computers, My Computer, DCOM Config and select Detail View from View Menu.

From the list we have to find DCOM Application ID with problematic permissions.

If we right click on selected Application ID and select Security Tab, everything is gray, because as administrator we don’t have permission to change DCOM Application permissions.

It is easy to change permissions for selected Application with Registry Editor (regedit.exe).

With Edit/Find command, we can find problematic Application ID in Registry.

It is located in HKEY_CLASSES_ROOT\AppId\{F72671A9-012C-4725-9D2F-2A4D32D65169}.

With right click and selected Permissions.., we can change permissions for specific AppId. First we need to change owner of registry Key.

Go to Advanced, Change Owner to Administrators group (local Administrators group, if computer is member of domain), select OK twice. Then open Permissions window once again and change permissions of Administrators group to Full Control.

Now we can return to Component Services Application (restart application after changing registry permissions or simply Refresh application list), find our Application ID, as it is written above.
If we right click on selected Application ID, we can now change Launch and Activation Permissions of Application.

We have to Add user that doesn’t have Local Activation Permission from Error Event. In our case we have to set Local Launch and Local Activation Permissions for user System.

That’s it. We will not see Event 10016 for selected application ID and specific user any more in our OS.

Enjoy!!!

Few days ago, I noticed that Exchange Server VM integration services were old and tried to update Hyper-V (Host is Windows Server 2012 R2) Integration Services of Exchange Server VM.
After restart, Exchange Server VM becomes unresponsive on below screen: Getting Windows Ready. Don’t turn off your computer.

I tried to restart VM few times, but our Exchange Server VM was unusable.

Solution:

Probably the best solution is to enter Boot Menu and run VM in Safe Mode.
For this we have to boot VM from Windows Server 2012 R2 ISO and instead of Install option, we select Repair your computer.
After selecting Troubleshoot, we enter Command Prompt.

We enable Boot Menu on our Windows Server 2012 R2 OS of Exchange Server VM by entering commands:
bcdedit /set {bootmgr} displaybootmenu yes
bcdedit /set {bootmgr} timeout 15

After VM reboot, we can enter Boot Menu by pressing F8 and select Safe Mode option.

In Safe Mode Exchange Server VM starts without problems.

Now, we have to disable all Exchange Services on VM (by changing Startup Type of services to Manual). After this we can reboot VM in normal way and machine will start.
Then we can update Integration Services on VM. After all is updated successfully, we enable Exchange Services again (by changing Startup Type of services to Automatic) and reboot VM.

After this Exchange Server is fully functional with up to date integration services.

I hope that Microsoft will solve this problem in the future.

Sometimes we want to reject Exchange mail sender according to a certain criteria. Suppose you want to block all e-mails addressed to a particular domain. This is easily done in Exchange admin center. Create new Mail flow rule, as shown below.

After selecting the sender and recipient domain, you have three options:

”Reject the message with the explanation”, where you can enter a short message why message was rejected

‘’Delete the message without notifying anyone’’

‘’Reject the message with the enhanced status code’’, where you must enter so called NDR (Non-delivery reports) code.

NDRs are system messages that report the delivery status of a message to the sender. NDRs are generated when a message cannot be delivered. If the computer can detect the reason for the failed delivery, it maps the reason onto a status code, and a corresponding error message is printed. For NDRs, most numeric error codes are reported in the form of “5.X.X” and are described as permanent failures.

More about NDRs: https://technet.microsoft.com/en-us/library/bb232118(EXCHG.80).aspx

In Exchange on-premises server you can use PowerShell cmdlet

Get-SystemMessage to view all NDRs in your organization, or use parameter

Get-SystemMessage –Original to display just embeded ones.

Any system message can be rewritten, if you are not satisfied with the original.

Example:

Get-SystemMessage En\Internal\5.7.1 Shows the original message for the 5.7.1 error code for english language

Set-SystemMessage En\Internal\5.7.1 -Text “Write here your custom message” Overwrites original message with custom message.