This is an interesting one I've been guessing at. Here's the high points:

• Provider supports Company 1.
• 3 people leave Company 1 and start their own company, Company 2.
• Company 2 is a direct competitor to Company 1.
• Company 2 buys Company 1.
• Company 2 wants to offboard Company 1's MSP, more of a one-man shop. This is because the MSP doesn't want to collaborate with us on supporting both companies under a proper merger can take place. I do want to collaborate, so they are telling him next week that we are taking over both companies.

During my time of trying to help out Company 2 users remote in and VPN into the Company 1 network, there is something odd with the VPN. The firewall doesn't come with any VPN software, as the provider has been using Windows built-in.

Here's the weird part that I can't get clarification with this person on... the VPN server hostname/address is exchange.domain.com ... putting in that info into the built-in VPN, it brings up an Outlook landing page within that window (not redirected to a web browser or anything of the sort). When I asked about the setup, and how the connection is interacting with Exchange, I'm told "they have one IP, so OWA https requests are forwarded".

That doesn't exactly make sense to me. I was thinking maybe Outlook Anywhere was configured and it's really only connecting to Exchange, rather than also being able to access network shares (I didn't try at the time as the user was in a hurry). If network shares are also accessible, what I'm wondering is why is there an Outlook landing page? Is it connecting directly to Exchange? I've never saw that before since I've always connected a VPN client to the firewall, and often Exchange has its own public IP.

@dbeato said in Synology NAS - Can't delete:

@bbigford said in Synology NAS - Can't delete:

@dbeato said in Synology NAS - Can't delete:

As an aside question, do you have it that it recycles the storage after certain time with Synology to Synology backuP?

What do you mean recycles? It's not doing an offsite move-delete if that's what you mean, it's copying it in case either building is lost. Maybe I don't understand the question.

So when I setup the backup between Synology devices, I make sure that after a certain time/age the backup device deletes the older snapshots/backups.

Ah, got it. What are you using for backup software that you'd rather your backup software not delete it? Also, are you using Synology CLI for that? I don't know that I've noticed that option in the GUI as part of the task creation.

@dbeato said in Synology NAS - Can't delete:

As an aside question, do you have it that it recycles the storage after certain time with Synology to Synology backuP?

What do you mean recycles? It's not doing an offsite move-delete if that's what you mean, it's copying it in case either building is lost. Maybe I don't understand the question.

@black3dynamite said in Synology NAS - Can't delete:

@nashbrydges said in Synology NAS - Can't delete:

If you're using rsync to sync the 2 NASs then there's no air gap. The systems are obviously networked together. What about using Backup Copy from Veeam instead of rsync. Just wondering is rsync may be the cause here.

Using rsync is pretty good at preserving permissions unless one forget to include option -a.

I used the GUI on this one.

@nashbrydges said in Synology NAS - Can't delete:

If you're using rsync to sync the 2 NASs then there's no air gap. The systems are obviously networked together. What about using Backup Copy from Veeam instead of rsync. Just wondering is rsync may be the cause here.

I'll probably go that route for long term. I love rsync but I may keep it only for specific cases.

@nashbrydges said in Synology NAS - Can't delete:

If you're using rsync to sync the 2 NASs then there's no air gap. The systems are obviously networked together. What about using Backup Copy from Veeam instead of rsync. Just wondering is rsync may be the cause here.

Air gap as in if one building was lost, the other is fine. I should have been more clear. Not two separate networks using wireless point to point.

@nashbrydges said in Synology NAS - Can't delete:

Could someone have logged in as administrator on the Offsite NAS and (accidentally) changed permissions on the "User" account?

No, I'm the only one who works with them at this time.

@scottalanmiller said in Synology NAS - Can't delete:

Worth a shot anyway.

It's seeing in a healthy state after monitoring constantly. I just don't understand what I could have done better to remove a backup chain and just free up space. I initially tried to delete the link and just re-establish it with the same name; couldn't do that though since it looks for the same name and -if it exists- it creates a new folder.

Deleted offsite backups shared directory and now seeding; will take 12 hours. Hope there is no environmental hazard during that time with onsite.

Not sure what I could have done better in this case.

@scottalanmiller said in Synology NAS - Can't delete:

@bbigford said in Synology NAS - Can't delete:

@scottalanmiller said in Synology NAS - Can't delete:

What method are you using to make the offsite copy? Is it just an RSYNC?

Yes. Onsite is fine, still a lot of storage available. Offsite is 95% full.

And RSYNC is syncing as that user, not as root?

Correct

@scottalanmiller said in Synology NAS - Can't delete:

What method are you using to make the offsite copy? Is it just an RSYNC?

Yes. Onsite is fine, still a lot of storage available. Offsite is 95% full.

@scottalanmiller said in Synology NAS - Can't delete:

Which of the two NAS are you looking at that you cannot delete?

Offsite

High Points:

• Using Veeam.
• Synology onsite NAS.
• Synology offsite NAS is in a building about 200 feet away, with an air gap.
• Owner of files is "User" << obfuscated.
• "User" has read/write on the parent folder, and all subdirectories and files/objects.
• Logged in as "User".
• Trying to purge an older backup chain in offsite backups results in a permissions error.
• Using rsync, user account is "User".

@dbeato said in Windows Server 2008 EOL?:

@bbigford Server 2008 Service pack 2 expires on 1/14/2020 as per below:

Hah, sorry. That was just another line in the exact link I posted. I could have scrolled just a tiny bit. Zoomed through to the line I was looking for and overlooked Service Pack 2. Plus, I got off work and had a couple drinks have remained completely sober.

@scottalanmiller said in List All Public Folders in Exchange or Office 365 with PowerShell:

Want to get a list of all of the public folders on your Exchange system, whether on premises or hosted, try this:

Get-PublicFolder -Identity "\" -Recurse | Get-PublicFolderClientPermission | where{$_.Accessrights -eq "owner"}

More on Get-PublicFolder from TechNet

That's pretty cool. I was wondering why you were piping into every owner since you could create public folders in Exchange without delegating owners, but then I had remembered you can create them on the client side as well after a root or folders are created in Exchange and added to the client, which is explained in your first pipe. Thanks for the note.

When the heck does this actually go EOL? Does anyone have a link that clearly states it? All I can find are forum threads.

I've found a thread from "that other forum" that states WS2k8 is officially EOL in 2020, but this Microsoft link shows you need to refer to Service Pack end date... which is only 3 years after it's release. The other columns show as N/A. Obviously it wasn't EOL 3 years later, so the verbiage isn't clearly stating when it actually ends. I'm only concerned with security updates, nothing else.

The question is going to come up, "why would you support this?!"

It's a HIPAA client and I have to retain the data for 7 years. I can save the VHD to another server and backup that server, thus backing up the VHD should we ever have an audit in the next 3 years for that data. There is a proprietary DB and a front end installed on that server, which is an old electronic medical records system. I really don't want to just export the DB and try to find the software later when an auditor says "part of retaining data requires you to make it highly available when we ask. That includes available client programs to connect to the database and pull that data as needed."

The other alternative is just convert it in the next 60 days when they move from Hyper-V to VMware ESXi for an infrastructure upgrade, then keep that VM running. To be clear, this is a dead system; nobody has used it since November and people knew that time was coming for around a year. I'm handing this account off to another engineer and want to just make this as easy as possible for them to hand over information and availability of that data to any HIPAA auditors. Part of that compliance audit is allowing EOL systems access to the network. I just need an EOL date for planning purposes. If my thought is correct, they'd have to cut network access for this system in 2 years, which they would then have to extract data from an offline system in the last year should there be a demand-for-data during that time beyond just a standard annual compliance audit.

@dbeato said in SPF issues:

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

This one is stumping me. I resolved another engineer's issue, but I don't see why there was an issue to begin with. Here are some high points:

• On-premises Exchange server.
• Another provider needed to be added to SPF, as they are a service that sends on behalf of the client's domain.
• v=spf1 mx a include:exchange.ourdomain.com include:mail.sendingproviderdomain.com ~all
• Above SPF record was present when issue was happening.
• I looked up their spf record, which was v=spf1 ip4..... many IPs.
• PTR for exchange.ourdomain.com resolves, using MXToolbox.
• Forward lookup is fine as well.
• Removed mx a include:exchange.ourdomain.com and added ip4:<OurPublicIP>
• v=spf1 ip4:<OurPublicIP> include:mail.sendingproviderdomain.com ~all

What I don't get is why the first SPF doesn't check out. There is a PTR record in GoDaddy, and a host record pointing at the correct IP. SPF should read "any MX records, and IPs, for exchange.ourdomain.com are allowed to send; including a provider, and for spoofing there will be a soft fail".

Where am I wrong?

SPF does not neck the mx records of the includes, it checks only the A and MX records of the domain with the SPF record. You should add the SPF record of the exchange.ourdomain.com Email Servers (Namely Office 365, G-Suite or any other email vendor).

On-prem Exchnage. I also saw a vendor that has theirs written as mx:<email.domain.com>... I've saw some written with a:<hostname> but not mx: ... Didn't know that was a thing.

So how would you write an spf record for our instance to have validation? It works now with the public IP, but I can't figure out why the FQDN doesn't work.

Is your exchange.ourdomain.com hsoted elsewhere than Internally?

Hosted? I'm not sure I understand the question. It's internal Exchange, record is in GoDaddy.

Yeah, l was wondering if it was Office 365 or same type outside the office. But in short having include:exchange.domain.com it is looking for all the SPF records on that subdomain which causes the failure on lookup.

Why does that cause a failure? Can you explain a little further?

Okay, so this is the SPF you had and was failing

v=spf1 mx a include:exchange.ourdomain.com include:mail.sendingproviderdomain.com ~all

Now this record was stating that the following records were allowed to send on behalf of your domain:
1-The MX records of your domain
2- The A records of your domain
3- The SPF record of exchange.ourdomain.com
4- The SPF record of mail.sendingproviderdomain.com.

Since you did not have an SPF record for exchange.ourdomain.com it was failing to register that as an allowed Sender.
If you wanted to include the exchange.ourdomain.com on your SPF it should be as below:

v=spf1 mx a ptr:exchange.ourdomain.com include:mail.sendingproviderdomain.com ~all

A PTR is what search for domain names on the SPF.

See more here:
http://www.openspf.org/SPF_Record_Syntax#include
http://www.openspf.org/SPF_Record_Syntax#ptr

Thanks for the clarification. At a very basic level, would it be correct to say include:exchange.ourdomain.com is creating essentially a circular lookup, since the SPF record there includes a sub domain that it is already trying to look up? Because of that reason, ptr:exchange.mydomain.com is looking at the IP... I could put ip4:<ourPublicIP>, but if I put ptr:exchange.mydomain.com I can change the public IP lookup in less places... this being one less place.

Is my thinking correct?

Yes, your thinking is correct.

Cool, thanks.

@dbeato said in SPF issues:

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

This one is stumping me. I resolved another engineer's issue, but I don't see why there was an issue to begin with. Here are some high points:

• On-premises Exchange server.
• Another provider needed to be added to SPF, as they are a service that sends on behalf of the client's domain.
• v=spf1 mx a include:exchange.ourdomain.com include:mail.sendingproviderdomain.com ~all
• Above SPF record was present when issue was happening.
• I looked up their spf record, which was v=spf1 ip4..... many IPs.
• PTR for exchange.ourdomain.com resolves, using MXToolbox.
• Forward lookup is fine as well.
• Removed mx a include:exchange.ourdomain.com and added ip4:<OurPublicIP>
• v=spf1 ip4:<OurPublicIP> include:mail.sendingproviderdomain.com ~all

What I don't get is why the first SPF doesn't check out. There is a PTR record in GoDaddy, and a host record pointing at the correct IP. SPF should read "any MX records, and IPs, for exchange.ourdomain.com are allowed to send; including a provider, and for spoofing there will be a soft fail".

Where am I wrong?

SPF does not neck the mx records of the includes, it checks only the A and MX records of the domain with the SPF record. You should add the SPF record of the exchange.ourdomain.com Email Servers (Namely Office 365, G-Suite or any other email vendor).

On-prem Exchnage. I also saw a vendor that has theirs written as mx:<email.domain.com>... I've saw some written with a:<hostname> but not mx: ... Didn't know that was a thing.

So how would you write an spf record for our instance to have validation? It works now with the public IP, but I can't figure out why the FQDN doesn't work.

Is your exchange.ourdomain.com hsoted elsewhere than Internally?

Hosted? I'm not sure I understand the question. It's internal Exchange, record is in GoDaddy.

Yeah, l was wondering if it was Office 365 or same type outside the office. But in short having include:exchange.domain.com it is looking for all the SPF records on that subdomain which causes the failure on lookup.

Why does that cause a failure? Can you explain a little further?

Okay, so this is the SPF you had and was failing

v=spf1 mx a include:exchange.ourdomain.com include:mail.sendingproviderdomain.com ~all

Now this record was stating that the following records were allowed to send on behalf of your domain:
1-The MX records of your domain
2- The A records of your domain
3- The SPF record of exchange.ourdomain.com
4- The SPF record of mail.sendingproviderdomain.com.

Since you did not have an SPF record for exchange.ourdomain.com it was failing to register that as an allowed Sender.
If you wanted to include the exchange.ourdomain.com on your SPF it should be as below:

v=spf1 mx a ptr:exchange.ourdomain.com include:mail.sendingproviderdomain.com ~all

A PTR is what search for domain names on the SPF.

See more here:
http://www.openspf.org/SPF_Record_Syntax#include
http://www.openspf.org/SPF_Record_Syntax#ptr

Thanks for the clarification. At a very basic level, would it be correct to say include:exchange.ourdomain.com is creating essentially a circular lookup, since the SPF record there includes a sub domain that it is already trying to look up? Because of that reason, ptr:exchange.mydomain.com is looking at the IP... I could put ip4:<ourPublicIP>, but if I put ptr:exchange.mydomain.com I can change the public IP lookup in less places... this being one less place.

Is my thinking correct?

@dbeato said in SPF issues:

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

This one is stumping me. I resolved another engineer's issue, but I don't see why there was an issue to begin with. Here are some high points:

• On-premises Exchange server.
• Another provider needed to be added to SPF, as they are a service that sends on behalf of the client's domain.
• v=spf1 mx a include:exchange.ourdomain.com include:mail.sendingproviderdomain.com ~all
• Above SPF record was present when issue was happening.
• I looked up their spf record, which was v=spf1 ip4..... many IPs.
• PTR for exchange.ourdomain.com resolves, using MXToolbox.
• Forward lookup is fine as well.
• Removed mx a include:exchange.ourdomain.com and added ip4:<OurPublicIP>
• v=spf1 ip4:<OurPublicIP> include:mail.sendingproviderdomain.com ~all

What I don't get is why the first SPF doesn't check out. There is a PTR record in GoDaddy, and a host record pointing at the correct IP. SPF should read "any MX records, and IPs, for exchange.ourdomain.com are allowed to send; including a provider, and for spoofing there will be a soft fail".

Where am I wrong?

SPF does not neck the mx records of the includes, it checks only the A and MX records of the domain with the SPF record. You should add the SPF record of the exchange.ourdomain.com Email Servers (Namely Office 365, G-Suite or any other email vendor).

On-prem Exchnage. I also saw a vendor that has theirs written as mx:<email.domain.com>... I've saw some written with a:<hostname> but not mx: ... Didn't know that was a thing.

So how would you write an spf record for our instance to have validation? It works now with the public IP, but I can't figure out why the FQDN doesn't work.

Is your exchange.ourdomain.com hsoted elsewhere than Internally?

Hosted? I'm not sure I understand the question. It's internal Exchange, record is in GoDaddy.

Yeah, l was wondering if it was Office 365 or same type outside the office. But in short having include:exchange.domain.com it is looking for all the SPF records on that subdomain which causes the failure on lookup.

Why does that cause a failure? Can you explain a little further?

@dbeato said in SPF issues:

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

This one is stumping me. I resolved another engineer's issue, but I don't see why there was an issue to begin with. Here are some high points:

• On-premises Exchange server.
• Another provider needed to be added to SPF, as they are a service that sends on behalf of the client's domain.
• v=spf1 mx a include:exchange.ourdomain.com include:mail.sendingproviderdomain.com ~all
• Above SPF record was present when issue was happening.
• I looked up their spf record, which was v=spf1 ip4..... many IPs.
• PTR for exchange.ourdomain.com resolves, using MXToolbox.
• Forward lookup is fine as well.
• Removed mx a include:exchange.ourdomain.com and added ip4:<OurPublicIP>
• v=spf1 ip4:<OurPublicIP> include:mail.sendingproviderdomain.com ~all

What I don't get is why the first SPF doesn't check out. There is a PTR record in GoDaddy, and a host record pointing at the correct IP. SPF should read "any MX records, and IPs, for exchange.ourdomain.com are allowed to send; including a provider, and for spoofing there will be a soft fail".

Where am I wrong?

SPF does not neck the mx records of the includes, it checks only the A and MX records of the domain with the SPF record. You should add the SPF record of the exchange.ourdomain.com Email Servers (Namely Office 365, G-Suite or any other email vendor).

On-prem Exchnage. I also saw a vendor that has theirs written as mx:<email.domain.com>... I've saw some written with a:<hostname> but not mx: ... Didn't know that was a thing.

So how would you write an spf record for our instance to have validation? It works now with the public IP, but I can't figure out why the FQDN doesn't work.

Is your exchange.ourdomain.com hsoted elsewhere than Internally?

Hosted? I'm not sure I understand the question. It's internal Exchange, record is in GoDaddy.