Add STSADM to your system path

Anyone who does anything with SharePoint knows that the Stsadm.exe command is indispensible. It’s used for so many administrative, troubleshooting, and maintenance tasks. Problem is, it’s buried way deep down inside the Program Files directory, and you need to dig down to that location before you can start using the command. Here’s a great tip for making Stsadm easier to get to and easier to use.
1. Open Notepad and enter the following commands. Each bullet represents one line in the text file:
• @echo off
• set path=%path%;c:\program files\common files\microsoft shared\web server extensions\12\bin
• d c:\
• @echo on
2. Save the file as “STSADM Command Prompt.bat” in a location accessible to both your normal user account and your administrative user account (if they are different). The batch file can be hidden away somewhere--but it's important that you have permission to read the file as both your normal user account and your administrative account.

3. Create a shortcut to the batch file. Put the shortcut somewhere very accessible, like on your desktop or in your Start menu.

4. Open the properties of the shortcut. On the TARGET line, add to the beginning of the line: cmd.exe /k
5. Click the Apply button. Windows will change cmd.exe /k to c:\windows\system32\cmd.exe /k.
• The Target line will now read:
C:\WINDOWS\system32\cmd.exe /k "path\STSADM Command Prompt.bat"
6. Click the Advanced button.
7. On Windows Vista or Windows Server 2008, select Run As Administrator. On Windows XP or Windows Server 2003, choose Run With Different Credentials (assuming you use a separate, administrative account to run Stsadm).
Double-click the shortcut. You’ll be prompted to run the shortcut with appropriate administrative credentials. Then a command prompt will open, set to the root of the C:\ drive (based on the third line in the batch file). Type path and press Enter. You’ll see that the system path now includes the folder in which Stsadm is found. That folder was added to the system path by the second line in the batch file.
Test the command prompt by typing STSADM /? and pressing Enter. You’ll see the usage information for Stsadm.exe displayed. Now you can use Stsadm commands to administer the server without having to dig into the deepest crevices of the Program Files folder.
OR

Add path to environment variables
Control Panel>Under System Properties, Advanced tab, Environment Variables button.
Select the "Path" system variable. Add your path to the SPRoot\BIN folder. Now all (future) command prompts have access to STSADM (and anything else in BIN folder).

JDE Writing to a SharePoint Site

System Requirements

Make Sure the WebClient Windows Service is launched and set to Automatic on the Source Server(Boe Server).



Find the correct UNC Path:

To locate this go the sharepoint site where you want to find out the UNC path and go to “Actions” then “Open With Internet Explorer” then record the unc path.





Job Setup for the destination column



Permissons:

Make sure the the account (ie..userid/password) running the schedule job has permissions to the sharepoint site.



Schedule the Job



Verify the Results:

Allowing Email Enabled SharePoint Lists & Libraries?

You can enable and configure e-mail support for the following types of lists and libraries in your sites:
• document libraries
• picture libraries
• form libraries
• announcements lists
• calendar lists
• blogs
• discussion boards

Concerns

People will turn on email enablement for their list or library and then start dumping into it.

Questions

Can we turn off this permission to all but a select few?
No, anyone with permissions to create a list can choose an e-mail address for the list when creating the list in an e-mail-enabled site.

To enable or configure incoming e-mail support for a list or library, you must have the Manage Lists permission on the list or library. The Manage Lists permission is granted by default to the Site name owners SharePoint group. This means that site owners will always have the option to email enable libraries/lists, and this can not just be trimmed out of permission levels. The actual permission reads: Manage Lists - Create and delete lists, add or remove columns in a list, and add or remove public views of a list. You cannot turn “manage lists” off without denying the ability to even create a list, it is all together.

Will there be a naming standard for these items?
We could not enforce this easily as the instructions for creating the email address on the MS site reads: In the E-mail address box, type a unique name to use as part of the e-mail address for this library. This means that users can create whatever address that they want.

Are these items going to be listed in the Address Book (Active Directory)?
Question asked in Forum

Who's going to be sending email to these (internal (authenticated/group members) people (what email & AD domain?), external people (CentraComm, DMZ SMTP servers), automated systems, etc)?
When configuring the e-mail security settings on a particular list or library, you can choose to allow only users who can write to the list or any user to archive e-mail to the list. Archiving e-mail from all senders allows everyone (including unauthenticated users) to write to your list or library. Because of the potential security risk, you should give this option careful consideration.

Will there be email size limitations?
The same size limitations as the upload size maximum. Currently set at 1.5 Meg.

Will we have to worry about spam to these addresses?
Yes if we allow anyone to email allows unauthenticated users including Spammers to send email to the list.

What domain are we going to use, and how will mail be directed to it (Exchange Send Connectors, MX records)?
Exchange Send Connectors be used (more discussion at bottom)

What happens when a list is removed? Is the object in AD removed automatically?
SharePoint will update AD accordingly to delete the corresponding contact from AD

What kind of storage requirements are we expecting? How will this affect performance (Sharepoint & SQL)?
We cannot truly predict the storage requirements for SharePoint if we allow incoming email. Setting up site quotas would be the only way to monitor the situation, and putting quotas in place after the sites have already been created and used would be a tedious process.

What changes need to be made in AD in order for list emails to work well? Security? Structure?
To use the Microsoft SharePoint Directory Management Service on a farm or server, you must configure the Central Administration application pool identity account to have the Create, delete, and manage user accounts right to the container that you specify in Active Directory. The preferred way to do this is by delegating the right to the Central Administration application pool identity account. An Active Directory administrator must set up the organizational unit (OU) and delegate the Create, delete, and manage user accounts right to the container.
Create new Organizational Unit in Active Directory and grant permission for the SharePoint service account using delegate control option. http://blogs.msdn.com/selvagan/archive/2008/01/26/incoming-email-configuration-moss.aspx

What’s up with the MX records?
After you add the IIS SMTP service, it will default to accepting email for the NetBios server name or, if defined in the network card properties, the DNS domain name of the server.
To get the SharePoint incoming email features to work within your organizations' email infrastructure, you don't need to configure the Directory Management Service feature within MOSS (it is not included with WSS anyway) but you may have to make some changes to the IIS SMTP service and your DNS server so that mail can be routed to the SharePoint server rather than your normal email server.
For wssdemo.com, I had to add the wssdemo.com domain as an alias because the server was part of another domain, so that the SMTP service would accept email for this domain. I also had to create a DNS MX record for this domain that points to the IP address of the SMTP/WSS server.



This causes email sent to @wssdemo.com to be placed in the drop folder on the SMTP server (as defined in the properties of the Local Default domain).
Before you try and get the SharePoint email integration working, you should test that email sent to this domain arrives in the drop directory (default location is C:\Inetpub\mailroot\Drop). You can do this from Outlook Express or you can use the SMTPDiag utility which you can download from here http://www.wssdemo.com/redir.aspx?ID=918
You should specify this directory location in the "Central Administration > Operations > Incoming E-Mail Settings" screen if you select the advanced options. http://www.wssdemo.com/Pages/Email.aspx

Other Sources:

http://justgeeks.blogspot.com/2009/01/sharepoint-incoming-e-mail-overview.html
http://office.microsoft.com/en-us/sharepointserver/HA100823061033.aspx
http://technet.microsoft.com/en-us/library/cc287879.aspx