Welcome to the packet-land.net-work
User Rating: / 17
PoorBest 

Have you ever seen plenty of spam mail in your inbox and noticed in the source FROM field that it's either your email address or some colleague’s email address, of your own domain and company as a sender?

This can happen if one of your domain email addresses has been spoofed by a spammer and then used to flood your mail server with what it’s called internal spam. But how is this achieved?

In Exchange Server 2010, the Accepted Domains section is where is stated on Exchange server which domains are valid to be used as source email addresses in order to push emails to the internet. But this means that an external user can connect to your company Exchange server and by providing any email address using your domain name will get accepted. That’s what the extensive Transport Permissions model in Exchange 2010 is there for, in order to prevent such spam to be delivered.

By default all the Receive Connectors on Exchange 2010 have the ms-exch-smtp-accept-authoritative-domain-sender permission which indicates whether an Accepted Domain can be used in the MAIL or FROM headers. When an external mail server submits mail to your Exchange server without authentication, as anonymous senders, that permission is being consult by the Exchange server in order to allow or block the email supplied by anonymous senders.

To avoid anonymous users sending mail using your domain you need to remove the ms-exch-smtp-accept-authoritative-domain-sender permission assigned to them. The command to remove this permission is shown below:

Get-ReceiveConnector “Internet ReceiveConnector” | Get-ADPermission -user “NT AUTHORITY\Anonymous Logon” | where {$_.ExtendedRights -like “ms-exch-smtp-accept-authoritative-domain-sender”} | Remove-ADPermission

As soon as this permission is removed, when anonymous senders try to submit mail to your Exchange server, it will consult the list of the Accepted Domains, and the result will be the following:

 

220 packetland.net Microsoft ESMTP MAIL Service ready at Fri, 03 Jan 2014 02:58:20 -0600
helo
250 packetland.net Hello [87.88.89.90]
mail from: This e-mail address is being protected from spambots. You need JavaScript enabled to view it
550 5.7.1 Client does not have permissions to send as this sender


Even if someone tries to use email address header spoofing in the email message body, as you can see below it fails:

 

mail from: This e-mail address is being protected from spambots. You need JavaScript enabled to view it
250 2.1.0 Sender OK
rcpt to: This e-mail address is being protected from spambots. You need JavaScript enabled to view it
250 2.1.5 Recipient OK
DATA
354 Start mail input; end with .
from: This e-mail address is being protected from spambots. You need JavaScript enabled to view it  
subject: Header spoofing

550 5.7.1 Client does not have permissions to send as this sender


As a conclusion in this article we have seen that removing the ms-exch-smtp-accept-authoritative-domain-sender permission stops spoofing of your domains and it is absolutely neccessary to be applied on internet facing Exchange servers to avoid the internal spam situation.
User Rating: / 9
PoorBest 

One of the most popular error messages you get on a Citrix XenApp server is the one that the IMA (Independent Management Architecture) service cannot start.

This could be caused due to various reasons such as Corrupt Datastore, Corrupt Service Account, Heavy Server Load, Corrupt Local Host Cache, XML Service Corruption etc.

In this article the specific error code described is occurring randomly, most often in multi-server environments consisting of Citrix XenApp 6.0 servers that haven't been rebooted in a long time or had recent Windows Updates applied. The error message shown in the image " windows could not start the citrix independent management architecture on local computer. For more information, review the System Event Log. If this is a non-microsoft service, contact the service vendor, and refer to service-specific error code -2147483647 " indicates that the local host cache of the Citrix Datastore server has been corrupt and needs to be re-created.

 

citrix-ima-wont-start

 

Recreating the Local Host Cache is considered a fairly simple and safe process. You can manually create the local host cache from the farm’s data store. If the Citrix IMA Service fails to start or you have a corrupt local host cache, you may need to recreate it.

To recreate the local host cache you need to follow the steps below:

STEP 1: Stop the IMA Service from the windows  services console.

STEP 2: Click on Start--->Run and type "cmd". Then in the command line type "dsmaint recreatelhc" and hit enter.

This command will perform 3 actions:

- Set the value of the registry key

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\IMA\RUNTIME\PSRequired to 1 (on 64bit systems),

or HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\IMA\RUNTIME\PSRequired to 1 (on 32bit systems).

- Deletes the existing local host cache (Imalhc.mdb)

- Creates a fresh blank copy of the local host cache (Imalhc.mdb)

STEP 3: Start the IMA Service from the windows  services console.

Once the IMA Service starts, the local host cache will get populated with a clean copy of all data from the data store and you are good to go.

It's a good idea to restart the server once all is complete in order to verify that all services do startup as normal.

User Rating: / 6
PoorBest 

In Cisco Call Manager Express installations, after the first implementation you may want to run a very basic command in order to make a test call to test that a dial peer or an extension works.

The command to accomplish this is the following:

csim start 100

where "100" represents the dial peer / extension you would like to test. Here is an example of the output received once executed, confirming correct function:
2811-CME#csim start 100
csim: called number = 100, loop count = 1 ping count = 0

csim err:csim_do_test Invalid event ID ev(48), cid(1369), disp(0)
csim: loop = 1, failed = 0
csim: call attempted = 1, setup failed = 0, tone failed = 0

2811-CME#
This command will only create a dummy VoIP call via CLI and will not interfere with any other function of the CME operation.
User Rating: / 7
PoorBest 

If you ever wondered what is the version of a Windows server system, or even of Windows PC then there is a very simple command to run in command prompt that will give you all the details you need. The command is shown below as well as the result that pops up on a Windows server 2008 R2 that was run on:

slmgr -dlv
result-screenshot

The same command also applies for all windows versions (e.g. Windows 7, Windows 8)

User Rating: / 7
PoorBest 

After a clean install on a Windows Server 2008 R2 and Citrix XenApp 6.5 installed and configured with a standard web interface site there is an error message coming up "HTTP Error 500.19 - Internal Server Error" on the Citrix web interface website.

This can occur if on the same server the WSUS server role has been installed.

More specifically the issue is produced by some Dynamic and Static compression modules that are added by the WSUS installation that affect the Xenapp web interface website operation.

The solution is simple and a matter of following the steps below:

STEP 1: Open up the IIS Manager by clicking on "Start--->Administrative Tools--->Internet Information Services (IIS) Manager" and clck on the server Hostname at the top left hand tree, which will reveal a few icons on the right.

STEP 2: Double click on the "Modules" icon on the right side and a list of different module options will come up.

STEP 3: Locate and right click on "DynamicCompressionModule" and choose "Unlock" and then locate and right click on "StaticCompressionModule" and choose "Unlock" too.

STEP 4: Next open up the XenApp website from the list of the web sites on the left and double click on the "Modules" icon on the right side again and a list of different module options will come up.

STEP 5: Locate and right click on "DynamicCompressionModule" and choose "Remove" and then locate and right click on "StaticCompressionModule" and choose "Remove" too.

STEP 6: Restart the IIS or the whole server if you like. Once you complete the steps described above the XenApp web interface website will revert to it's normal operation and should work fine.

mod_vvisit_countermod_vvisit_countermod_vvisit_countermod_vvisit_countermod_vvisit_countermod_vvisit_counter
mod_vvisit_counterToday416
mod_vvisit_counterYesterday542
mod_vvisit_counterThis week1450
mod_vvisit_counterLast week2420
mod_vvisit_counterThis month13156
mod_vvisit_counterLast month14538
mod_vvisit_counterAll days991582

We have: 2 guests, 1 bots online
Your IP: 54.162.213.67
 , 
Today: Aug 24, 2016
35.9%United States United States
8.7%United Kingdom United Kingdom
7%India India
6.8%Australia Australia
3.6%Germany Germany
3.2%Brazil Brazil
2.9%Canada Canada
2.7%Russian Federation Russian Federation
2.1%Italy Italy
1.8%Singapore Singapore

Today: 155
Yesterday: 142
This Week: 434
Last Week: 657
This Month: 2609
Last Month: 3518
Total: 119600